Re: "mount" bug

[Harry Kalogirou <harkal@gmx.net>]

> This was my fault; since the machine was happily using both floppy drives 
> under Windows 95 I didn't bother to run the BIOS Setup program. While 
> checking the "impossible" I discovered that it was set up for only for a 
> 1.2M first drive. After correcting this to 1.44M first drive and 1.2M 
> second drive, it worked.
> 
> This leads to an interesting question: is the fact the floppy mounted, but 
> was otherwise inaccessible a bug or a feature? If ELKS should be handling 
> all possible low-level functions then it's a bug in the mount() function 
> (presumably in the kernel). If mount invokes the ROM BIOS to reduce the 
> size of the kernel then it's a feature, and perhaps it could be reduced 
> further by using the ROM BIOS for more of the diskette-handling (which 
> might have made the diskette accessible despite my incorrect settings).

All floppy access goes through the BIOS. There is a direct floppy
version of the code in the kernel source tree but probably needs a lot
of work. Also the size of the code might be a problem. On the other hand
if we make it work, floppy access wont pause the whole system any more.

> I now think the "Cannot fork", reduced free memory and deteriorating
> system are *not* diagnostic of an incorrect BIOS setup, but rather a
> hardware incompatibility and maybe an ELKS bug revealed by the
> incompatibility. The system on which this occurred has a VL-Bus/EISA
> motherboard and a "bootable" EISA SCSI card. I noticed that when I
> repeated "ps" its process ID jumped by large amounts, and the problems
> occurred when the process ID was displayed as a negative number, after
> which the init process disappeared entirely; I also saw two "init" entries
> once. I suspect the hardware is somehow spawning, then killing new init
> processes frequently, and that when the process ID is negative (or maybe
> when it rolls over to positive again) killing the second init also kills
> the first. "Cannot fork" seems to appear when there's no active init
> process. I'll investigate further, but these should have their own threads
> in the mailing list.

"Cannot fork" is emmited by the shell, when the fork() system call
fails. The system call will fail :

1) If there are no more process slots available.
2) There is not enough free memory.

What exacly happend there, I realy can't tell. The only thing I can tell
is that something "very" bad happed there. I personaly havedn't seen
ELKS behave like that before. 

Harry