Re: ELKS v0.78 bugs fixed
Greg Haerr writes: > > Al, > After receiving ELKS v0.78, I compiled Microwindows and Nano-X for > it and found we need one more kernel patch, and have several other items > in elkscmd, some of which were missed. Overall, ELKS 0.78 is a great step > forward for ELKS and MicroWindows. > > The following items are fixed in my ELKS 0.78 patch #1: > > ELKSCMD: > login.c: set TERM=ansi, remove debug printf's > etc/issue: change to 0.78 I got things a bit messed up in this release because I did things in the wrong order. The etc/issue file is automatically generated from the elks Makefile, but I had not updated it when I built the release. Releasing elkscmd and elks at the same time is becoming more work than is easy to deal with as elkscmd grows. I think it would be best to switch over to a different release model. elkscmd updates can be released regularly with date stamped version MAJOR.MINOR version release don't really have any meaning for elkscmd as it contains so many packages. I can then release the kernel on its own with its disk images much more easily. > sash: fix to allow environment variables to be unset by specifying only > the environment variable name, e.g.: "setenv TERM" will delete any TERM environment > variable. BTW, this requires my putenv.c rewrite for the dev86 kit. putenv() was >completely > rewritten, to fix the fact that it basically doesn't work. Quite alot of the libc stuff in dev86 is untested. The utent.c file in elkscmd is just there as a fix until I submit the patch to the version in dev86. > > ELKS: > fix kernel exec code when chmem field is exactly 64K. This is required > or the new nano-X won't run, it says "Out of memory" > I was aware of this bug, and it was in my todo list. Thanks for looking at it. Al
Re: tiny sash typo
Scott Lanning writes: > > ~elkscmd/sash/sash.c, line 382, > > #ifdef CND_ALIAS > > should be > > #ifdef CMD_ALIAS > > Anyway, CMD_ALIAS is not defined (c.f. sash/config.h). > Thanks for the patch, it is now integrated. Al
Re: Good news????
Luke writes: > > > In the mtools directory there was this readme: > 8< > mtools - tools to read msdos floppies from unix pc > > Compiled with a couple of tweaks, but cannot read disks, even under dosemu. > > Al ([EMAIL PROTECTED]) Sun 11 Oct 1998 16:20 > 8< > > I just deleted one exit(1) (line 101 of init.c); and mdir works fine. > The others seem to work too. > Where it said Can't read FAT or whatever was all crap. > Good news, but looking at the code I think we need to work out why the read() call the reads the FAT is not returning the correct value, rather than just inoring the error condition. Al
Re: compiling 0.0.78
Werner Heuser writes: > > Hi, > > writing the Linux-Laptop-HOWTO and Linux-Ecology-HOWTO, I'm > interested in the ELKS project and started with 0.0.77 and > a Commodore C286-LT laptop: > > First I took the image.zip file and it worked great out of the box. > But when installing it on the hd I didn't find 'mknod'. > > So I took 0.0.78, compiled 'mknod' build the files in /dev and > started with the 0.0.77 boot floppy. But after inserting the > root floppy, I got a message 'pgrnpulling pgrnpulling ' > ad infinitum. > > So I decided to use the 0.0.78 image.zip. This worked for the > boot floppy, but changing to the root floppy doesn't work. It will not > start. I found out the floppy control LED doesn't went down, when > the boot floppy is finished. BTW 'mknod' is still missing. Yep, mknod got missed out when I automated building the disk images. I have fixed this, and it should work fine in the next release. You can find mknod in the file_utils directory of the elkscmd package. > > I tried to make a 0.0.78 kernel than and got this error: > > make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block' > bcc -D__KERNEL__ -O -i \ > 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c > boot/crt1.c:5.25: error: cannot find include file arch/segment.h > make[1]: Leaving directory `/usr/local/src/elks/arch/i86' > make[1]: *** [boot/crt1.o] Error 1 > make: *** [Image] Error 2 > I don't understand why you get this error. WHat version of dev86 are you using? Al
RE: Herc Support
On Sunday, July 18, 1999 4:21 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : How do you enable herc support in microwin? Greg? : Find the makefile lines that have scr_bios.o and scr_herc.o in them; comment out the first one and uncomment the second... Greg
RE: rfs (new filesystem for ELKS)
On Sunday, July 18, 1999 6:01 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : > Why has elks chosen a 16 bit inode number for stat when the rest of the world : > has 32 bit inode numbers? It probably is a good idea to use 32bit inode numbers. : : Small computers, small problems. : Alan's response is an accurate overall encapsulation of the problem. A bit of history: elks is based on linux ext2 is based on linux minix is based on minix, whose executable file format was copied which used 16 bit inode numbers... (remember stat?)
RE: Microwindows for Hercules
: The code in devdraw.c is very naiive. It assumes pixel plotting is the underlyin : op. On many cards line slices are the underlying operation, horizontal or : vertical. What you probably want to do is generate a series of : : draw_horizontal(x,y,l) : : or : draw_vertical(x,y,l) : : calls for most things : That's a good idea. This would certainly speed up diagonal lines on systems with a fast horizontal line draw. The vertical doesn't add much, as most video planes aren't optimized for vertical line drawing. Currently, there aren't any applications that draw diagonal lines though, so the speed issue is mute. : > This might be useful when bitblt is implemented though... : : Having 32K of offscreen memory is always useful. : Definitely. I plan on adding offscreen drawing memory, but it requires some big architecture changes. Greg
RE: rfs (new filesystem for ELKS)
On Mon, 19 Jul 1999, Greg Haerr wrote: > > Why has elks chosen a 16 bit inode number for stat when the rest of > > the world has 32 bit inode numbers? It probably is a good idea to use > > 32bit inode numbers. I'd say the simple answer is that because ELKS is targetted at 16bit (or less, ie. not 32bit) machines, that 32bit inode numbers aren't a good idea. Same reason that under Linux/x86, we use 32bit instead of 64bit, simply because we've got a 32bit CPU (or 16bit in the case of ELKS). Davey
RE: compiling 0.0.78
: : > : > I tried to make a 0.0.78 kernel than and got this error: : > : > make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block' : > bcc -D__KERNEL__ -O -i \ : > 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c : > boot/crt1.c:5.25: error: cannot find include file arch/segment.h : > make[1]: Leaving directory `/usr/local/src/elks/arch/i86' : > make[1]: *** [boot/crt1.o] Error 1 : > make: *** [Image] Error 2 : > : : I don't understand why you get this error. WHat version of dev86 are you : using? : Likely the problem is the link -s is missing in the /usr/bcc/include for the arch and linuxmt dirs.
RE: rfs (new filesystem for ELKS)
On Monday, July 19, 1999 11:08 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote: : On Mon, 19 Jul 1999, Greg Haerr wrote: : : > > Why has elks chosen a 16 bit inode number for stat when the rest of : > > the world has 32 bit inode numbers? It probably is a good idea to use : > > 32bit inode numbers. : : I'd say the simple answer is that because ELKS is targetted at 16bit (or : less, ie. not 32bit) machines, that 32bit inode numbers aren't a good : idea. Same reason that under Linux/x86, we use 32bit instead of 64bit, : simply because we've got a 32bit CPU (or 16bit in the case of ELKS). : Actually, the inode width should be dependent on the size of disks attached, not the processor specs...
RE: Microwin Mouse
On Sunday, July 18, 1999 1:13 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : I have got a mouse to work in mirowin at last! dont know if it was me or : what, I could not for the life of me get any mouse to work. So in dispare I : tryed my 10 year old genus mouse in 3-button mode in "pc" mode and it : worked! : : anyway I just thought I would say because there were some people having some : probs and I thought it might help fix them. : This is fixed in ELKS 0.78. The bug was that any mouse that emited NUL bytes won't work. Any mouse that emits ASCII will. Thanks for the info Greg
RE: ELKS v0.78 bugs fixed
: I got things a bit messed up in this release because I did things in the : wrong order. The etc/issue file is automatically generated from the elks : Makefile, but I had not updated it when I built the release. Releasing : elkscmd and elks at the same time is becoming more work than is easy to : deal with as elkscmd grows. I think it would be best to switch over to a : different release model. elkscmd updates can be released regularly with : date stamped version MAJOR.MINOR version release don't really have any : meaning for elkscmd as it contains so many packages. I can then release : the kernel on its own with its disk images much more easily. As long as if you have both elks and elkscmd, you can "make comb" etc. We're getting significant enhancements by posting them together though. I know my work depended on it. I don't mind splitting them if it's too much work, but we're finding alot of kernel bugs from elkscmd... : Quite alot of the libc stuff in dev86 is untested. The utent.c file in : elkscmd is just there as a fix until I submit the patch to the version in : dev86. : Send Rob utent, he'll integrate it I'm sure. Greg
Re: compiling 0.0.78
Greg Haerr schrieb: > > : > : > > : > I tried to make a 0.0.78 kernel than and got this error: > : > > : > make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block' > : > bcc -D__KERNEL__ -O -i \ > : > 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c > : > boot/crt1.c:5.25: error: cannot find include file arch/segment.h > : > make[1]: Leaving directory `/usr/local/src/elks/arch/i86' > : > make[1]: *** [boot/crt1.o] Error 1 > : > make: *** [Image] Error 2 > : > > : > : I don't understand why you get this error. WHat version of dev86 are you > : using? > : > > Likely the problem is the link -s is missing in the /usr/bcc/include for the > arch and linuxmt dirs. I have set the links from /usr/lib/bcc/include (Debian 2.1) to the ELKS kernel and it compiled without any error now. But the main problem still remains. When booting from the root floppy I can't change to the root floppy. After the message: "VFS: Insert root floppy and press ENTER" I do so, but the system sits there idle, but nothing happens. With 0.0.77 the floppy drive LED went down after finishing the boot floppy, but now it doesn't. Cheers :-> werner -- Werner Heuser | There is no time, /~~ LiLAC - Linux with Laptop Computers | ... to make war ... /~~~ Berlin, Germany | -Lou Reed-/ T. +49 30 349 53 86 <[EMAIL PROTECTED]> www.snafu.de/~wehe/index_li.html
RE: compiling 0.0.78
: > Likely the problem is the link -s is missing in the /usr/bcc/include for :the : > arch and linuxmt dirs. : I have set the links from /usr/lib/bcc/include (Debian 2.1) to the ELKS : kernel and : it compiled without any error now. But the main problem still remains. : When : booting from the root floppy I can't change to the root floppy. After : the : message: "VFS: Insert root floppy and press ENTER" : I do so, but the system sits there idle, but nothing happens. I do a "make comb" and run off the combined root floppy. I haven't tested your particular configuration. Try running off a comb disk, with the linux Image in /boot/linux. With : 0.0.77 : the floppy drive LED went down after finishing the boot floppy, but : now it doesn't. Al and I are looking into this. It happens the same way on my system. Greg
filesystem bug
I've been playing with the bug reported at the bottom of ~elks/BUGS. I think I have observed a pattern: If a file with filename length equal to 14 characters is used as the source file for one of 'cp', 'mv', or 'ln', thereafter the filename is not recognized by them and 'ls'. For instance, if I > cp aa foo no error occurs and 'ls' produces the expected result. However, if I next > cp aa bar an error "aa: No such file or directory" is emitted and 'ls' also complains. Furthermore, if I > ln foo aa the listing will show two "aa"s!!! Then the fresh "aa" will be recognized for the following 'cp', 'mv', or 'ln', but is tarnished by that operation again.. I have reason to believe the "No such file or directory" is returned by namei() which is called in sys_stat() in ~elks/fs/stat.c, but that's as far as I've gotten.. I'm new at this, so my bug squashing is proceeding very slowly.. If nobody is interested, no problem, I'll eventually figure it out anyway so don't waste your time. I just thought you guys know alot more and might know instantly what is the problem. I apologize if it's a known or unworthy problem. I have notes for the experiments I tried if anyone wants them. There are alot, and many are garbled by printk() output. --Scott
RE: filesystem bug
: the listing will show two "aa"s!!! Then the fresh : "aa" will be recognized for the following 'cp', 'mv', : or 'ln', but is tarnished by that operation again.. I have : reason to believe the "No such file or directory" is returned by : namei() which is called in sys_stat() in ~elks/fs/stat.c, but : that's as far as I've gotten.. : I'm new at this, so my bug squashing is proceeding very slowly.. : If nobody is interested, no problem, I'll eventually figure it : out anyway so don't waste your time. I just thought you guys know : alot more and might know instantly what is the problem. I apologize : if it's a known or unworthy problem. : : I have notes for the experiments I tried if anyone wants : them. There are alot, and many are garbled by printk() output. : Keep going! This kind of work is greatly appreciated! It sounds like you're near a breakthrough. I think the problem may lie in the fact that the fileames *aren't* NUL terminated,and that strncmp may need to be used, or the memcpy_fromfs changed to get the user-name level filename. Greg
RE: rfs (new filesystem for ELKS)
On Tue, 20 Jul 1999, Greg Haerr wrote: > On Monday, July 19, 1999 11:08 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote: > : On Mon, 19 Jul 1999, Greg Haerr wrote: > : > : > > Why has elks chosen a 16 bit inode number for stat when the rest of > : > > the world has 32 bit inode numbers? It probably is a good idea to use > : > > 32bit inode numbers. > : > : I'd say the simple answer is that because ELKS is targetted at 16bit (or > : less, ie. not 32bit) machines, that 32bit inode numbers aren't a good > : idea. Same reason that under Linux/x86, we use 32bit instead of 64bit, > : simply because we've got a 32bit CPU (or 16bit in the case of ELKS). > : > > Actually, the inode width should be dependent on the size > of disks attached, not the processor specs... Yes, this is true, the inode numbers for RFS don't actually exceed 16 bit for partitions less than 64meg in size. However, I cannot see the problem in using 32 bit inode numbers, very little math ever occurs on then, and they use a whole 2 bytes more in memory. (I know, it is a bad attitiude :), but 32bit inodes are throughout the kernel already.) Beau Kuiper [EMAIL PROTECTED]
RE: ELKS 0.0.78 released
A few of us had this exact same problem on PS/2 machines, and I believe the problem ended up not being the disk drive but rather the keyboard not being detected. A simple test, if you can do it, would be to try the combo boot/root image, and see if it hangs or not. Sence you are using 5.25" disks (right?) I take it you don't have a PS/2 as they came with 720k drives. I believe the combo image requires at least 720k disk space, so if you have a machine that can read a 720k disk, it may be a good test. Hope this helps, good luck. Dan On Thu, 15 Jul 1999, Jeff Stanton wrote: > The problem is that the system does not mount the root disk (AFAIK) I let > it spin the root disk for 5 minutes after pressing enter, but nothing > happens. But since it works for you, it's probably a problem with my > disks. I found another pair of disks, and will try it again tomorrow. > -Jeff >
Herc in Microwin
I fired up my old beast last night, a v20 640k with a herc card, I ran my compiled copy of microwin with herc support, and it worked! WELL done to greg and whoever helped write that driver! On the down side it did take a little long for it to load, try 10 min! So if it is to be used the code has to be somewhat speeded up. I did not try to move any windows because I did not have a mouse pluged in and it would have taken too long. I am not realy an expert, but a v20 is faster that an 8086/8088 so it might be worse on those. All that I can think of doing is 1.adding 8087 support 2.speeding up code 3. anyone else have ideas?? From Thomas Stewart :-) at [EMAIL PROTECTED] __ Get Your Private, Free Email at http://www.hotmail.com
