Re: In-kernel units for block numbers, etc ...

[mlelstv%serpens.de@localhost (Michael van Elst)]

kre%munnari.OZ.AU@localhost (Robert Elz) writes:

>This is (it appears) caused by this line in cgdioctl() ...

>        dk_getdisklabel(dksc, 0 /* XXX ? (cause of PR 41704) */);

>The 0 ((dev_t)0) and XXX have been there since cgd.c 1.1, so this
>is nothing new!

That's vp->v_rdev stored as cs->sc_tdev. A value 0 is wd0.

>The panic traceback was ...

>vpanic() at vpanic+0x140
>snprintf() at snprintf
>startlwp() at startlwp
>calltrap() at calltrap+0x19
>disk_read_sectors() at disk_read_sectors+0x47
>read_sector() at read_sector+0x1d
>scan_mbr() at scan_mbr+0x32

>Somehow, we need to get the dev_t for the device passed down, or stored
>somewhere.   Currently that info seems to be missing.

The underlying device is cs->sc_tdev. But the disklabel must be read from
the cgd device itself. Currently dk_getdisklabel is called with a dev_t
for wd0a (major=0, unit=0, part=0)

On the other hand, the disklabel reading code doesn't actually
care about the device driver selected by the dev_t argument as
the strategy routine is already passed as an additional argument
(and it always uses RAW_PART). So that's more like cgd0d.

The code seems to be somewhat bogus anyway. It is not necessary
to read the disklabel when the device is attached. The label
is read again (and correctly) when the cgd device is opened.
The call must be used for some side effect.

The correct thing is therefore to drop the dk_getdisklabel call.

Can you verify that this just solves the problem?


-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."