RE: [Bug-hurd] Problem with dev/glue/block.c (More Ramblings)

[Brent Fulgham]

> The problem seems to be here:
> 
> /dev/glue/block.c init_partition (roughly 1005)
> if (slice >= gd->max_p
>   || gd->part[MINOR (*dev) & mask].start_sect < 0
>   || gd->part[MINOR (*dev) & mask].nr_sects <= 0)
>       return D_NO_SUCH_DEVICE;
> 
> What's happening is that the &mask causes the offset into gd->part
> to drop from 127 down to 63.  I think that the mach routines that
> set this up are placing partitions on the primary slave IDE 
> interface (hd1) above offset 64.  If I take the &mask out in all
> places where it is used, my offset is 127, GNUmach can find
> the valid partition (with start_sect >= 0 and nr_sects > 0)
> and all is well.
> 
Indeed, according to linux/drivers/block/ide.c, this is the
correct behavior (I can see that hdb [or hd1 in Hurd] should
have minor value 64).

So perhaps the problem is that the code at line 952 in 
glue/block.c stops prematurely, either because gd->max_p is too
low, or because the d->inode.i_rdev = *dev | i; isn't doing
what it should for the case of slave drives.

I.e., instead of counting 0-63 (which is what it does right
now), it should count 64-128 to pick up hd1.

So I'm going to assume for now that the linux driver code is
correct, since it has not been modified, and since it seems to
be filling the slots as defined (primary slave should reside at
minor values 64+).

I'll instead investigate why our "init_partition" routine is
not properly accessing slots 64+ when the Hurd is initializing
a slave drive.

In fact, this explains why people with the Hurd on hd0 are able
to boot successfully, but hd1 cannot.  Similarly, I would
expect people on hd2 to be okay, but hd3 to have problems.
Anecdotal evidence so far bears this out, since all three of us
experiencing the problem have the hurd located on hd1.

Thanks,

-Brent
>From brent.fulgham@xpsystems.com  Sat Sep 23 19:11:25 2000
Received: from thresher.xpsystems.com (proxy.xpsystems.com [207.171.47.2])
        by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id TAA03734
        for <bug-hurd@gnu.org>; Sat, 23 Sep 2000 19:11:24 -0400
Received: by THRESHER with Internet Mail Service (5.5.2650.21)
        id <TFSS1YCX>; Fri, 22 Sep 2000 14:22:16 -0700
Message-ID: <EDFD2A95EE7DD31187350090279C6767EE7A7D@THRESHER>
From: Brent Fulgham <brent.fulgham@xpsystems.com>
To: OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
Cc: bug-hurd@gnu.org
Subject: RE: [Bug-hurd] Problem with dev/glue/block.c (Resolution)?
Date: Fri, 22 Sep 2000 14:22:13 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
Sender: bug-hurd-admin@gnu.org
Errors-To: bug-hurd-admin@gnu.org
X-BeenThere: bug-hurd@gnu.org
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:bug-hurd-request@gnu.org?subject=help>
List-Post: <mailto:bug-hurd@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>, 
<mailto:bug-hurd-request@gnu.org?subject=subscribe>
List-Id: Bug reports for the GNU Hurd <bug-hurd.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>, 
<mailto:bug-hurd-request@gnu.org?subject=unsubscribe>
List-Archive: http://mail.gnu.org/pipermail/bug-hurd/

I think the problem with the dev/glue/block.c code is
that the "& mask" actions should not be taken when
referencing into the partition table.

When we setup the partition table on boot, we
use the Linux kernel driver "msdos_partition"
function, which in turn calss the "add_partition"
command.

Tracing the operation with a bunch of printk's, I
can see that we go to initialize the partition
at around minor value 63 (which is the first partition
of the slave device).

We check that current_minor & mask (64 & 0x4F) is not
zero (which happens if our current_minor rises above 48
on the master device, or rises past 127 for the secondary
device).  This puts us at "1" (the anding masks the other
bits) and we enter the add_partition, passing a table
value of 64.

add_partition uses the 64 as-is (no masking), and stores
the partition table data at 64+.

When we add the masking in dev/glue/block.c for our
table offset, we incorrectly point ourselves at "1"
(so in effect we are trying to find slave drive
partition "1" at the table location for master drive
partition "1").  Since I have no such drive, I get
an error message.  People without the Hurd on the
primary drive get a message that the file can't be
found.

The Linux driver code does use the "& mask" every time
it displays the drive name:

maj = "hd";

char unit = (minor >> hd->minor_shift) + '0';   // Yields '1'
part = minor & mask;            // This yields "2" rather than "65"
sprintf(buf, "%s%cs%d", maj, unit, part);

Which yields the desired "hd1s2".

I think it was incorrect to add the "& mask" operation to 
our partion table offset.  I suspect that the cause of the
IDE CD-ROM problem is of a different nature.

The reason people with the Hurd on the primary master drive
do not see a problem with the new code is that their primary
slave has major=0, minor=0 and any bit shifts are no-ops.

Could someone review this logic and see if they agree with
me?  Otherwise, I think we should back out the & operators
in the partition table offset calculations.

Thanks,

-Brent