PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2)

[Greg 'groggy' Lehey]

On Saturday, 29 March 2003 at 10:45:43 +0000, james wrote:
> Hi Greg
>
> Thanks for your response!
>
>> #6  0xc0220332 in dsioctl (dev=0xc1383200, cmd=0x8004646d, data=0xcb307d58 "\001", flags=0x2, sspp=0xc1328568)
>>     at ../../kern/subr_diskslice.c:356
>> #7  0xc021fd5b in diskioctl (dev=0xc1383200, cmd=0x8004646d, data=0xcb307d58 "\001", fflag=0x2, p=0xca10fee0)
>>     at ../../kern/subr_disk.c:267
>> #8  0xc140b5af in ?? ()
>> #9  0xc140969b in ?? ()
>> #10 0xc140988e in ?? ()
>> #11 0xc140c461 in ?? ()
>> #12 0xc024efa2 in spec_ioctl (ap=0xcb307de4) at ../../miscfs/specfs/spec_vnops.c:306
>>
>> This is different from the other crash.  It looks like it happens in
>> Vinum.  Take a look at vinum(4) or
>> http://www.vinumvm.org/vinum/how-to-debug.html for details of how to
>> bring life into them.
>
> I have been looking at this page, and I'm not clear what else is needed, or what
> you mean by "bringing life into them". I followed the steps to analyse a kernel
> panic, and provided the output... unfortunately I don't have the knowledge to
> fix it myself.

You need to load the symbols from the kld.  Both pages tell you how to
do that.

>> It's not clear what's trying to write the label, but looking at the
>> locals of the dsioctl frame would help.
>
> I provided this output in gdb.txt - the code and locals for frame 6 are:
>
> (kgdb) f 6
> #6  0xc0220332 in dsioctl (dev=0xc1383200, cmd=0x8004646d, data=0xcb307d58
> "\001", flags=0x2, sspp=0xc1328568)
>     at ../../kern/subr_diskslice.c:356
> 356             sp = &ssp->dss_slices[slice];
>
> (kgdb) l
> 351             struct diskslices *ssp;
> 352             struct partition *pp;
> 353
> 354             slice = dkslice(dev);
> 355             ssp = *sspp;
> 356             sp = &ssp->dss_slices[slice];
> 357             lp = sp->ds_label;
> 358             switch (cmd) {
> 359
> 360             case DIOCGDVIRGIN:
>
> cmd = 0x0
> data = 0xcb307d58 "\001"
> flags = 0x2
> error = 0xcb307d58
> lp = (struct disklabel *) 0xffffffff
> old_wlabel = 0x0
> openmask = 0x4b
> part = 0x2
> slice = 0x2
> sp = (struct diskslice *) 0x8c
> ssp = (struct diskslices *) 0x0
>
> I must admit, I was a little confused as to why cmd was suddenly 0x0
> considering that dsioctl was called with cmd = 0x8004646d,

This is possibly a strangeness of gdb.  It's not relevant, however.

> but as I'm no kernel hacker there's probably a very good reason for
> it! Is it possible it's being overwritten and that's why we panic?

No.

Look at the line where it happened:

> 356             sp = &ssp->dss_slices[slice];

Now look at ssp:

> ssp = (struct diskslices *) 0x0

ssp is taken indirectly from sspp:

> 355             ssp = *sspp;

So the caller is passing invalid data in sspp.  That's potentially
Vinum; you need to get those symbols loaded and find out what Vinum is
doing.

To the rest of -questions: is this interesting?  If not, I'll take it
offline.  I need at least one "yes please" reply to continue beyond
the next exchange of messages.

Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address and phone numbers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20030330/ccece77a/attachment.bin