Date: Sun, 30 Mar 2003 07:58:30 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: james <jamesp@hisser.org> Cc: questions@freebsd.org Subject: Re: PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2) Message-ID: <20030329222830.GF18846@wantadilla.lemis.com> In-Reply-To: <Pine.LNX.4.44.0303291034420.16757-100000@greebo.hisser.org> References: <20030329005659.GC72294@wantadilla.lemis.com> <Pine.LNX.4.44.0303291034420.16757-100000@greebo.hisser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--SnV5plBeK2Ge1I9g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --SnV5plBeK2Ge1I9g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+hh4OIubykFB6QiMRAsVPAKCSKBsEbHVOcRncW0jm6B59rjeodwCgj5PU ilwQFCOkuAkLjb30CpilLsM= =QFHP -----END PGP SIGNATURE----- --SnV5plBeK2Ge1I9g--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030329222830.GF18846>