From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 11 04:05:57 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74CEC16A4CE; Thu, 11 Nov 2004 04:05:57 +0000 (GMT) Received: from idiom.novusordo.net (novusordo.net [216.194.67.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B2A43D1D; Thu, 11 Nov 2004 04:05:57 +0000 (GMT) (envelope-from cdjones@novusordo.net) Received: from [127.0.0.1] (localhost.novusordo.net [127.0.0.1]) by idiom.novusordo.net (Postfix) with ESMTP id 15EDB54D1; Wed, 10 Nov 2004 21:05:53 -0700 (MST) Message-ID: <4192E520.1090307@novusordo.net> Date: Wed, 10 Nov 2004 21:05:52 -0700 From: Chris Jones User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg 'groggy' Lehey References: <200411100810.iAA8AUoR023993@freefall.freebsd.org> <20041110232304.GO948@wantadilla.lemis.com> In-Reply-To: <20041110232304.GO948@wantadilla.lemis.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-bugs@FreeBSD.org cc: ru@FreeBSD.org cc: kris@FreeBSD.org Subject: Re: misc/73757: vinum fails to load from rc.conf and kernel panics; works fine if started after boot X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 04:05:57 -0000 Greg 'groggy' Lehey wrote: > This is a known problem in 5.3 with old Vinum. Basically "it don't > work". Hopefully soon you'll be able to use new Vinum ("gvinum") for > this purpose. What I'm trying to do is RAID-1 over two HDDs; it's ok if the data isn't available at booting and has to wait for manual intervention to start vinum or for a script to do it from /usr/local/etc/rc.d/ or so on. In other words, while not having vinum running at boot is irksome, it's not a showstopper for what I'm doing. >> Unfortunately, I don't have the exact addresses for the >> {instruction, stack, frame} pointers from that attempt handy at the >> moment, but I'll send them your way as soon as possible. > > > This would be of such limited use that most people wouldn't bother > looking at them. You really need a stack trace, preferably a dump. Alright. I built a kernel using the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING, set MAXMEM to 128*1024 so that it'd dump cleanly, ensured that the vinum.ko was of the correct vintage, set rc.conf to start vinum and store kernel dumps onto a swap partition, and booted with it with vinum_load in loader.conf. As expected, a kernel panic ensued: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x60 fault code = supervisor read, page not present instruction pointer = 0x8:0xc05e8a2f stack pointer = 0x10:0xc8151a1c frame pointer = 0x10:0xc8151a1c code segement = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 127 (vinum) trap number = 12 panic: page fault Uptime: 2s I then rebooted in single user mode to stop vinum from loading and try to recover coredumps. Unfortunately, savecore didn't see any coredumps stored on the swap partition. So, I added 'options DDB' to the kernel configuration file (and 'options KDB', as 'make depends' complained that kdb had to be enabled for ddb to work) and recompiled, installed the new kernel, made sure that vinum.ko was made as part of the new kernel, made sure that vinum was to start on boot, and then rebooted. This resulted in the following panic & stack trace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x60 fault code = supervisor read, page not present instruction pointer = 0x8:0xc05edf4f stack pointer = 0x10:0xc813fa1c frame pointer = 0x10:0xc813fa1c code segement = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 127 (vinum) [thread 100069] Stopped at devsw+0xb: cmpl $0,0x60(%edx) db> where devsw(0,66,c140dc00,140dc00,c813fa50) at devsw+0xb init_drive(c140dc00,0,66,1,c140dc00) at init_drive+0x92 check_drive(c14a7c00,c14a7c08,408,c09f2c61,1) at check_drive+0x4c vinum_scandisk(c140fa00,c14a8000,c14fe840,c1482200,c813fb40) at vinum_scandisk+0x220 vinum_super_ioctl(c148220,c400464b,c14a8000,c813fb34,c813fb20) at vinum_super_ioctl+0x4d0 vinumioctl(c1482200,c400464b,c14a8000,3,c130de10) at vinumioctl+0x39 spec_ioctl(c813fb88,c813fc34,c067002b,c813fb88,c08c0360) at spec_ioctl+0x120 spec_vnoperate(c813fb88) at spec_vnoperate+0x13 vn_ioctl(c14ba94c,c400464b,c14a8000,c12bbd80,c130de10) at vn_ioctl+0x187 ioctl(c130de10,c813fd14,3,1,296) at ioctl+0x545 syscall(2f,2f,2f,0,1) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281450b7, esp = 0xbfbfe52c, ebp=0xbfbfe958 --- db> show reg cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xc0877520 dead_cdevsw ecx 0xc08de6c0 Giant edx 0 ebx 0xc130de10 esp 0xc813fa1c ebp 0xc813fa1c esi 0x1 edi 0xc140dc00 eip 0xc05edf4f devsw+0xb efl 0x10203 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 devsw+0xb: cmpl $0,0x60(%edx) [Apologies for the alignment on the registers --- I was retyping that by hand.] I couldn't see any obvious way to get ddb to save the core somewhere useful, so I don't have that available to send to you (unless you can suggest a way to get it, in which case I can reproduce this fairly easily and get it). Cheers, Chris