NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/linux/10410

Internet Message Format | 1992-09-10 | 2.5 KB

Path: sparky!uunet!haven.umd.edu!darwin.sura.net!ra!tantalus!eric
From: [e-mail] (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: 0.97pl4 breaks SCSI extended partition code
Message-ID: <[e-mail]>
Date: 10 Sep 92 22:05:12 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Distribution: world
Organization: Naval Research Laboratory
Lines: 41

In article <[e-mail]> [e-mail] (David Metcalfe) writes:
>I've tried the patch out and it also cures my problem.  It's
>interesting that the extended partition could be read first time with
>0.97pl2 but not with pl4.  There must have been a small change in the
>timing.

    No, the problem is more insidious than that.  Drew kind of hinted
at it when he swore at the bootstrap loader, but I will explain.

    Previously, the array sd_sizes was uninitialized, which means that
it was in the bss section.  A normal C program can count on data items
in the bss section as being initialized to 0, but this is not always the
case with the kernel.  It really depends a lot on the bootstrap loader.
It appears as if lilo is able to zero the bss section, but shoelace does not.
As I recall, if you boot your kernel from a floppy, then the bss is not cleared
as well.  I could be all wet on this, though.

    This being said, what was happening was that the sd_sizes array was
initialized with junk when the system was trying to read the partition tables.
If that junk happened to be 0, then you would be unable to read the partition
table for the extended partition, and if it was non-zero (and positive??),
then linux would be able to read the parition table.  A seemingly unrelated
change would shift things around in memory, and thus could lead to the
partition size apparently becoming 0.

    Note that once the partition tables have been read, then the data
is read out from the partition structures, and sd_sizes is set to the correct
numbers.

    The way the kernel is supposed to work, blk_size[8] should be NULL
until the partition tables have been read.  Just after sd_sizes is set to the
correct numbers, then blk_size[8] is set to point to sd_sizes.  As long as
blk_size[8] == 0, then the test in make_request() is skipped.

    I am beginning to wonder if there is a way for the kernel itself to
clear the bss section before anything really gets going.  This problem is a
fairly easy trap to fall into, and it can easily lead to spurious behavior.

--
Eric Youngdale
[e-mail]