Date: Sat, 29 Mar 2003 10:45:43 +0000 (GMT) From: james <jamesp@hisser.org> To: Greg 'groggy' Lehey <grog@FreeBSD.org> Cc: questions@freebsd.org Subject: Re: PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2) Message-ID: <Pine.LNX.4.44.0303291034420.16757-100000@greebo.hisser.org> In-Reply-To: <20030329005659.GC72294@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0303291034420.16757-100000>