PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2)
james
jamesp at hisser.org
Sat Mar 29 02:45:56 PST 2003
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
More information about the freebsd-questions
mailing list