Subject:
Re: ELKS problems
From:
Alistair Riddoch ####@####.####
Date:
29 Jun 1999 11:26:26 -0000
Message-Id: <199906291120.MAA25430@penelope.ecs.soton.ac.uk>
Greg Haerr writes:
>
> Al,
> I worked on getting up to date this weekend on the linux-86 devkit (v0.14.8)
> and ELKS (v0.77). After quite a few compile time problems, I got everything
> compiling and working. I'll detail the problems later, and submit a patch.
>
> I can't get Micro-Windows to work with the serial mouse driver. It appears
> there's still possibly a bug in select(). Basically, the mouse works for about 1 second
> and then freezes. This is only the case if I move the mouse rapidly on startup. I
> modified mou_ser.c to use /dev/ttys0 and mousetype "pc", as I use a logitech mouse,
> but this shouldn't affect anything. If mou_ser.c is compiled -DTEST=1, it will
> run as a standalone app, and everything works fine. (it prints the x, y, buttonstatus
> to the console.) If I run Microwindows and then move the mouse, nothing happens
> after 1 second, and then when I hit ESC to quite Microwindows, and run the mou_ser
> test program, it spits out 50 or so mouse moves that appeared to be queued up in
> the kernel?? It appears the serial driver queues stuff inbetween close/open's.
> Have you seen any of this activity?
I have seen something like this, but it has never frozen on me. In nano-X,
whenever I stop moving the mouse, the cursor stops moving (as expected),
but when I start moving it in the oposite direction, it moves a few pixels
in the same direction as before, then changes to move in the new direction
as if some bytes got stuck in the queue. I suspect this is a glitch in the
select code. I will dig into it.
>
>
> Also, when trying to set environment variables, what shell do you use?
> I can't get sash to set environment variables, and when I run sh, it chops the PATH
> and other env vars short, as though the env space is too small...
I have seen problems with env vars getting chopped, but was not able to
track down where it happened. Almost certainly a bug involving strlen()
somewhere in libc, or the shell. sash is far too primitive to be used as a
real shell. I include it still because it is so small and stable that it is
a good test platform for running binaries.
>
> Finally, I don't yet understand how you build images.zip. There are
> root, boot and comb images, but the Makefiles in elkscmd and elks appear only to make
> the following:
Making the contents of images.zip is not fully automatic, but most of the
work is done by the Makefiles. I change the Makefile a bit between buidlign
comb and root (modify size etc.)
>
> elks "make disk" makes boot, which seems to be called root in distribution.
Checking with my copy, boot in images.zip is definatly a boot kernel image,
and root is a root disk image.
> elkscmd "make floppy" makes root, which seems to be called comb...
> Isn't there a standard makefile function to make these images?
Make floppy attempts to build an image of a combined disk, but calls it
root.
Make min_rfs makes a small root disk without kernel boot loader on it.
>
> On my system (Caldera 2.2) the dev86 package won't make. It
> requires an old /usr/bin/ar (this core dumps), and a change in elksemu to include
> <sys/time.h>. I will send a patch for this.
>
> In addition, the elkscmd requires changes in byacc/Makefile
> and ash/mknode.c, and uses a redefinition of utmp stuff in utent.c. I'll send
> a patch on this as well.
>
From what you are saying I gather that you have not been able to get in
touch with Reb de Bath about the changes to Dev-86? I looks as though we
will have to put together an new patched version. The utent.c in elkscmd
fixes some major bugs in the dev86 version. I included it until the patch
was merged into dev86, but this has not happened.
Al
