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

[james]

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.

> > The kenel is panicking in dsioctl(), kern/subr_diskslice.c:356. I've
> > had a look in there, but I really have no idea what it's trying to
> > do - I can't even work out what the ioctl is. I'm no kernel guy :(
> 
> The ioctl is the cmd parameter passed to diskioctl, 0x8004646d.
> That's DIOCWLABEL.  Finding them isn't easy, but basically:
> 
> 0x8 -> _IOW macro.  We're writing.
> 004    length to write
> 64     ioctl type ('d').  You'd go looking for a regular expression
>        _IOW.*'d'.
> 6d     ioctl number (109).  This one is in /sys/sys/disklabel.h:
> 
> #define DIOCWLABEL	_IOW('d', 109, int)	/* write en/disable label */

Thanks - that's helpful :)

> 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, 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?

> > I appreciate this may not be a bug in Vinum, but it certainly seems
> > like it's being triggered by vinum.
> 
> Yes, that's reasonable.
> 
> Greg

Cheers,

James