Re: double fault when using fssconfig + repetitive savecore problem

[theo borm <theo_nbusr%borm.org@localhost>]

theo borm wrote:
> trying to debug my debug-enabled kernel (gdb /var/crash/netbsd.7 
> /var/crash/netbsd.7.core) results in: 
I guess I was a bit naive, assuming that this syntax would be useful to 
debug a kernel core dump.

Trying again while following the manual at 
http://www.netbsd.org/docs/kernel/#debugging_a_kernel_crash_dump gives me:

# gdb ./netbsd.gdb
GNU gdb 6.5
<snip>
This GDB was configures as "x86_64--netbsd"...
(gdb) target kvm /var/crash/netbsd.17.core
#0 0xffffffff80536e66 in cpu_reboot (howto=260, bootstr=<value optimized 
out>)
at ../../../../arch/amd64/amd64/machdep.c:700
700 dumpsys();
(gdb) bt
#0 0xffffffff80536e66 in cpu_reboot (howto=260, bootstr=<value optimized 
out>)
at ../../../../arch/amd64/amd64/machdep.c:700
#1 0xffffffff8047ea18 in panic (
fmt=0xffffffff809be875 <Address 0xffffffff809be875 out of bounds>)
at ../../../../kern/subr_prf.c:253
#2 0xffffffff80538714 in trap (frame=0xffff8000079edc20)
at ../../../../arch/amd64/amd64/trap.c:256
#3 0xffffffff80100eda in calltrap ()
#4 0xffffffff8047d8fb in kprintf (fmt0=0x0, oflags=Cannot access memory 
at address 0xffffffffffffff7c
)
at ../../../../kern/subr_prf.c:1458
Previous frame inner to this frame (corrupt stack?)
(gdb)



The error message scrolling by during the kernel panic was:

# fssconfig -c -x fss0 / /tmp/backing
uvm_fault(0xffffffff80c911c0, 0xffff800001a13999, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff803bc40e cs 8 rflags 10206 cr2 
ffff800001a13400 cpl 0 rsp ffff800007a35160
panic: trap
Begin traceback
uvm_fault(0xffff800007642170, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff80532e4c cs 8 rflags 10246 cr2 0 cpl 0 
rsp ffff800007a34d10
panic: trap
Faulted in mid-traceback; aborting...
dumping to dev 0,1 offset 4032288
dump 79 78 <snip> 2 1 succeeded


So, what's happening? fssconfig causes a page fault, which tries to 
initiate a traceback, which pagefaults itself? So presumably the gdb 
backtrace applies to the traceback?...



Regards, Theo

p.s. Two things to note: 1) I've made the memory allocated to the KVM 
smaller (80M instead of 1024M), but that changes little besides making 
unzipping a core dump a bit faster. 2) I had previously booted directly 
into the netbsd.gdb kernel, but now I've used the stripped version.