From: <jb1@btstream.com>
To: Harry Kalogirou <harkal@gmx.net>
Cc: Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: "mount" bug
Date: Sat, 26 Oct 2002 01:55:09 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.33.0210260124250.31977-100000@olympus.btstream.com> (raw)
In-Reply-To: <1035545532.5491.4.camel@cool>
On 25 Oct 2002, Harry Kalogirou wrote:
> > /dev/fd1 seems to mount, but be inaccessible.
> >
> > After booting ELKS 0.1.1 from a 3-1/2" diskette in /dev/fd0, "mkdir /mnt",
> > "ls -l /" shows 2 hard links and a 32-byte size for mnt.
> >
> > "mount /dev/fd1 /mnt", when /dev/fd1 contains a 5-1/4" ELKS diskette,
> > shows:
> > fd: probing disc in /dev/fd1
> > fd: /dev/fd1 probably has 15 sectors and 80 cylinders
> > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> >
> > "ls -l /" now shows 10 hard links and a 160-byte size for mnt.
> >
> > "ls /mnt" now shows:
> > /mnt:
> > /mnt/in/sh
> > : No such file or directory
> >
> > After this point, "meminfo" shows *more* free and the system rapidly
> > deteriorates ("Cannot fork", a blank commandline prompt, a garbage
> > commandline prompt, etc.)
> >
> > Changing /mnt's permissions, owner and group don't help. Interchanging the
> > 3-1/2" and 5-1/4" drives didn't help, although there were more error
> > messages from mount. Using 5-1/4" drives for both /dev/fd0 and /dev/fd1
> > (with an ELKS 0.1.0 diskette in /dev/fd1) didn't help.
> >
>
> I tried it on my machine, but with 2 3-1/2 drives and it works fine.
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).
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.
next prev parent reply other threads:[~2002-10-26 8:55 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 [this message]
2002-10-26 14:49 ` Harry Kalogirou
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=Pine.LNX.4.33.0210260124250.31977-100000@olympus.btstream.com \
--to=jb1@btstream.com \
--cc=harkal@gmx.net \
--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.