bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Louis L. Perley III
Subject: Re: [Bug-hurd] Problem with dev/glue/block.c (More Ramblings)
Date: Wed, 27 Sep 2000 23:06:56 -0600

Please remove me from this mailing list, as I can no longer actively use the
hurd.
----- Original Message -----
From: Brent Fulgham <brent.fulgham@xpsystems.com>
To: Brent Fulgham <bfulgham@debian.org>; OKUJI Yoshinori
<okuji@kuicr.kyoto-u.ac.jp>
Cc: <bug-hurd@gnu.org>
Sent: Friday, September 22, 2000 2:25 PM
Subject: RE: [Bug-hurd] Problem with dev/glue/block.c (More Ramblings)


> > 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
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]