> 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
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
