misc/73757: vinum fails to load from rc.conf and kernel panics; works fine if started after boot

[Chris Jones]

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