bug-hurd
[Top][All Lists]
Advanced

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

Patch: Accessing the CD-ROM == Bad


From: Brent Fulgham
Subject: Patch: Accessing the CD-ROM == Bad
Date: Fri, 22 Sep 2000 21:18:35 -0700
User-agent: Mutt/1.2.5i

After further experimentation I am convinced that the patch adding
masks to the partition handling serves no purpose other than to
make it impossible for the Hurd to read slave drives.

Observe:

> I have trouble accessing the CD-ROM drive from GNU/Hurd.  I have the
> Hurd running in a VMware virtual machine, with a virtual drive on hd0,
> and a virtual ATAPI CD-ROM on hd1.
> 
> After login in as root, I do
> 
>     # cd /dev
>     # MAKEDEV hd1
>     # showtrans hd1
>     /hurd/storeio hd1
>     # cat hd1
>     cat: hd1: Invalid argument
> 
> What could be wrong here?  How can I get more information?

[ ... later ... ]

> I get this:
> 
>     # devprobe hd1; echo $?
>     hd1
>     0
> 
> So it looks like hd1 is there as far as GNU Mach is concerned, right?
>   

[ ... later still ... ]

> After some investigation, I came up with the following patch to GNU
> Mach that solves this problem for me:
> 
> Index: block.c
> ===================================================================
> RCS file: /cvs/gnumach/linux/dev/glue/block.c,v
> retrieving revision 1.3
> diff -u -r1.3 block.c
> --- block.c     1999/06/27 23:51:47     1.3
> +++ block.c     2000/08/15 00:02:54
> @@ -1597,7 +1597,17 @@
>      case DEV_GET_SIZE:
>        if (disk_major (MAJOR (bd->dev)))
>         {
> +         unsigned real_minor;
> +
>           assert (bd->ds->gd);
> +         
> +         real_minor = MINOR (bd->dev) >> bd->ds->gd->minor_shift;
> +         if ((real_minor << bd->ds->gd->minor_shift) != MINOR (bd->dev))
> +           real_minor = MINOR (bd->dev);
> +

[ ... snip ... ]

> 
> I have no idea what I really did, all I noticed was that
> device_get_status was returning a bogus size for hd1 because it
> accessed bd->ds->gd->part[64], and that I needed to shift the minor
> number to get to the right index, which is 1.  However, shifting
> always made the system fail in other ways, when calling
> device_get_status for a dev number of 0x301, which apparantly refers
> to my root partition hd0s1.
>

Which would be expected, because now the master (IDE) drive is
mapping onto the same partition slot as the slave (CD-ROM) drive.

The proper index was probably supposed to be 65, which might be
the true cause of the problem.  Perhaps the Hurd CD-ROM handling
code has an error someplace?

> So I'm confused now.  I hope someone can devise a real fix.
> 

Unfortunately, the only purpose this patch serves is to completely
cripple "slave" drives on each IDE controller.  The mask that is
applied turns of the high two bits on the minor number for the
device.  The underlying cause of Marius's troubles are elsewhere.

The Linux sources clearly state that slave drives have minor values
above 64, while master drives are 0 through 64.  While this is a
good kludge to get the CD-ROM drive working under VM-ware, it
has made the Hurd unusable for anyone trying to work with slave
drives on an IDE driver.

I suspect that the true cause of the the CD-ROM problem is either
within VMWare itself, or in the special ide-cd codebase.  I spent
a fair amount of my time looking through there for clues, but I
don't see anything obvious.

Since Marius indicates his 2.0.39 kernel works properly, and the
driver code comes from that Linux kernel, I suspect ide/ide-cd are
both fine.

We might need to look at how CD-ROM devices are handled within the
Hurd's block.c code, but since I don't have one on my hurd machine
I can't investigate further.

In the meantime, I urge that we back out the "mask" modifications
to the CVS sources immediately, as they have caused the Hurd to
stop functioning for at least three people (and counting).

> "Resource lost" messages from fsck.ext2 for hd0s1.  Apparently, hd0s1
> specified a minor_shift of 6, but its minor number is not supposed
> to be shifted (my thoughts, probabyl not reality).  So I put a check
> in that would shift the minor number only when all its shifted-out
> bits are zero.

I.e., when you have a 64 (which signifies a slave drive).

Regards,

-Brent


reply via email to

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