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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
