From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Kalogirou Subject: Re: "mount" bug Date: 26 Oct 2002 17:49:07 +0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <1035642211.5492.41.camel@cool> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" To: jb1@btstream.com Cc: Linux-8086 > 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