OKUJI Yoshinori <[EMAIL PROTECTED]> writes:
> From: Marius Vollmer <[EMAIL PROTECTED]>
> Subject: BUGFIX (sort of): Accessing the CD-ROM
> Date: 15 Aug 2000 02:05:08 +0200
>
> > After some investigation, I came up with the following patch to GNU
> > Mach that solves this problem for me:
>
> What "solves" means? Don't you just get "Invalid argument" any
> longer, or "cat" succeeds?
The CD-ROM works like I expect it to: I can mount it with settrans,
list its contents and generally work with it in a normal way.
> ??? As far as I see, your patch does nothing. REAL_MINOR always
> equals to MINOR (BD->DEV). What was the motivation that you
> introduced this code?
The itself patch is probably completely useless, it was only meant to
demonstrate what I changed to get the CD-ROM to work. After thinking
longer about this (i.e. the next morning in the shower), I now am
pretty sure that my understanding of Mach and the Linux drivers that
I imagined to have the evening before is completely wrong. I would be
happy to work with you on a real fix.
However, the original motivation was this: I traced my problems to
device_get_status returning -2048 as the size of hd1. After patching
Mach to return the constant 50Meg when bd->dev == 0x340, the CD-ROM
worked. Looking further, I noticed that the minor number is shifted
by gd->minor_shift when the device is opened. I reversed that in
device_get_status by right shifting it by the same amount. I then got
"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.
> Please be more specific. What really happens? "fail" has too many
> meanings. You can use the same word, when gnumach panics, when a
> translator died, when gnumach hangs, or others.
The main point of my message was that I was confused about what is
going on and hoped that someone who know the code would pint me in the
right direction. I guess I should have made that more clear.
> BTW, when Hurd accesses to the CD-ROM drive, what values are stored
> in BD->DEV and BD->DS->GD->PART[0]? I suspect that VMware just doesn't
> provide the correct capacity of a CD-ROM.
bd->dev == 0x340
bd->ds->gd->part[0].start_sect == 0
bd->ds->gd->part[0].nr_sects == 1023435.
bd->ds->gd->part points to the same hd_struct object that is used for
hd0s1, with dev==0x301.
I will continue to investigate this, but probably at a slow pace. If
there is anything you want me to try, I would be happy to do so.
