"mount" bug

"mount" bug

[jb1]

/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.


SOURCE PACKAGES:
        elks-0.1.1.tar.gz, elkscmd_20020501.tar.gz, elksnet-0.1.1.tar.gz,
        Dev86src-0.16.0.tar.gz
CVS PATCHES:
        elksnet/ktcp/ip.c Version 1.10 (only on the 3-1/2" diskette)
COMPILED UNDER:
        Red Hat 7.0 Linux, kernel 2.2.16-22

Re: "mount" bug

[Harry Kalogirou]

> /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.

Harry

Re: "mount" bug

[jb1]

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.

Re: "mount" bug

[Harry Kalogirou]

> 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

fork bug [WAS: Re: "mount" bug]

[jb1]

On 26 Oct 2002, Harry Kalogirou wrote:

> "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. 

There appears to be a bug in the "get_pid()" function from fork.c. The 
code fragment:
    if (++last_pid == 32768)
        last_pid = 1;
must eventually fail because last_pid is declared as type pid_t, which is 
typedef'ed as __s16, which is in turn typedef'ed as signed short int. 
Since signed 16-bit numbers roll over from 32767 to negative numbers, they 
can never equal 32768. A possible fix might be:
    if ( (++last_pid && 0x7fff) == 0 )
        last_pid = 1;
or, perhaps smaller and faster:
    if !( (last_pid++) &= 0x7fff )
        last_pid++;
The latter may have superfluous parentheses because I'm not sure of the 
precedence, and whether "variable++" is smaller and faster than 
"++variable" is probably compiler-dependent.

Re: fork bug [WAS: Re: "mount" bug]

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

> On 26 Oct 2002, Harry Kalogirou wrote:
> 
> > "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. 
> 
> There appears to be a bug in the "get_pid()" function from fork.c. The 
> code fragment:
>     if (++last_pid == 32768)
>         last_pid = 1;
> must eventually fail because last_pid is declared as type pid_t, which is 
> typedef'ed as __s16, which is in turn typedef'ed as signed short int. 
> Since signed 16-bit numbers roll over from 32767 to negative numbers, they 
> can never equal 32768. A possible fix might be:
>     if ( (++last_pid && 0x7fff) == 0 )
>         last_pid = 1;
> or, perhaps smaller and faster:
>     if !( (last_pid++) &= 0x7fff )
>         last_pid++;
> The latter may have superfluous parentheses because I'm not sure of the 
> precedence, and whether "variable++" is smaller and faster than 
> "++variable" is probably compiler-dependent.
> 

Commited...

Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]