From owner-freebsd-questions@FreeBSD.ORG Sat Mar 29 02:45:54 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3CB137B401 for ; Sat, 29 Mar 2003 02:45:54 -0800 (PST) Received: from greebo.hisser.org (greebo.hisser.org [62.49.72.114]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AC1C43FBD for ; Sat, 29 Mar 2003 02:45:53 -0800 (PST) (envelope-from jamesp@hisser.org) Received: (qmail 16901 invoked by uid 500); 29 Mar 2003 10:45:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Mar 2003 10:45:43 -0000 Date: Sat, 29 Mar 2003 10:45:43 +0000 (GMT) From: james To: Greg 'groggy' Lehey In-Reply-To: <20030329005659.GC72294@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: questions@freebsd.org Subject: Re: PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2003 10:45:56 -0000 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