reproducible panic on 8.2-RELEASE, but no core file

[Andriy Gapon]

on 23/08/2011 23:05 Aragon Gouveia said the following:
> Hi,
> 
> I'm experiencing a reproducible kernel panic that would be really nice to debug,
> but unfortunately no core file is getting generated.  I don't have console
> access either.  All I can get so far is this, from syslog:
> 
> Aug 23 19:51:38 <kern.crit> estranged kernel:
> Aug 23 19:51:38 <kern.crit> estranged kernel: Fatal double fault:
> Aug 23 19:51:38 <kern.crit> estranged kernel: eip = 0xc0593b2e
> Aug 23 19:51:38 <kern.crit> estranged kernel: esp = 0xe5583fe4
> Aug 23 19:51:38 <kern.crit> estranged kernel: ebp = 0xe5584010
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0; apic id = 00
> Aug 23 19:51:38 <kern.crit> estranged kernel: panic: double fault
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0
> Aug 23 19:51:38 <kern.crit> estranged kernel: panic: 0xc4263b40 must be migratable
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0
> Aug 23 19:51:38 <kern.crit> estranged kernel: panic: 0xc4263b40 must be migratable
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0
> [SNIP - above two lines repeated alot]
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0kernel trap 12 with
> interrupts disabled
> Aug 23 19:51:38 <kern.crit> estranged kernel: panic:
> Aug 23 19:51:38 <kern.crit> estranged kernel: 0xc4263b40 must be
> migratablekernel trap 12 with interrupts disabled
> Aug 23 19:51:38 <kern.crit> estranged kernel: kernel trap 12 with interrupts
> disabled
> Aug 23 19:51:38 <kern.crit> estranged kernel: cpuid = 0
> Aug 23 19:51:38 <kern.crit> estranged kernel: kernel trap 12 with interrupts
> disabled
> Aug 23 19:51:38 <kern.crit> estranged kernel: panic:
> 
> My dumpdev is set:
> 
> $  ls -l /dev/dumpdev
> lrwxr-xr-x  1 root  wheel  11 Aug 23 19:56 /dev/dumpdev@ -> /dev/ad4s1b
> 
> But savecore reports:
> 
> Aug 23 19:56:34 <console.info> estranged kernel: No core dumps found.
> 
> Any advice for getting a core file? :)

Not sure about the core file - I think that we do not attempt to do a dump when
we get a doublefault which is what you have, but not sure about this.
Also, those secondary panics might be coming from the sched_bind() call at the
start of boot() function in sys/kern/kern_shutdown.c.

For a start you can try adding DDB to your kernel config and capturing a stack
trace of the panic from the ddb prompt.

-- 
Andriy Gapon