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