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

[Brent Fulgham]

On Thu, Sep 21, 2000 at 06:24:36PM +0900, OKUJI Yoshinori wrote:
> > Hurd to be unable to mount IDE drives properly (i.e., a
> > formerly working system will now be unable to boot,
> > complaining that the drive is not available.).
> 
>   I'm not sure why, since no problem occurs in my environment (both in
> IDE and in SCSI). So you should investigate your problem yourself. Try
> to track the function "device_open" in linux/dev/glue/block.c, and see
> where the function returns incorrectly (possibly the return value is
> D_NO_SUCH_DEVICE).
> 

I can't finish debugging this tonight, but I think I can get it
by the end of the weekend.

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.

The Linux routines are setting these partitions to be at
locations 64-127.  I'm not sure if they are also in error.

In fact, playing with /dev/drivers/block/genhd.c indicates
that the table of IDE drives starts at 65 and runs through 68.
(we allocate the partition in msdos_partition, and use
the add_partition routine to set it).  But everything seems
to be off by a factor of 4.

I'll try to play a bit more tomorrow, but it might help to
understand what the & was supposed to accomplish in the
Hurd glue code.

-Brent