From: Harry Kalogirou <harkal@gmx.net>
To: jb1@btstream.com
Cc: Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: "mount" bug
Date: 26 Oct 2002 17:49:07 +0300 [thread overview]
Message-ID: <1035642211.5492.41.camel@cool> (raw)
In-Reply-To: <Pine.LNX.4.33.0210260124250.31977-100000@olympus.btstream.com>
> 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
next prev parent reply other threads:[~2002-10-26 14:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-25 9:28 "mount" bug jb1
2002-10-25 13:30 ` Harry Kalogirou
2002-10-26 8:55 ` jb1
2002-10-26 14:49 ` Harry Kalogirou [this message]
2002-10-27 12:57 ` fork bug [WAS: Re: "mount" bug] jb1
2002-10-27 19:49 ` Harry Kalogirou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1035642211.5492.41.camel@cool \
--to=harkal@gmx.net \
--cc=jb1@btstream.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.