All,
We are currently compiling the fc6 hypervisor with crash_debug=y.
However, a recently committed node (d78b31dd07e8d46032546dea2d68da229bf812c5,
commited 9/27) seems to have broken this. The symptoms are that rebooting dom0
goes into an infinite panic loop in the hypervisor. I tracked it down to
debugger_trap_immediate(). When dom0 makes the hypercall for shutdown, it ends
up in dom0_shutdown:
void dom0_shutdown(u8 reason)
{
debugger_trap_immediate();
switch ( reason )
{
case SHUTDOWN_poweroff:
{
printk("Domain 0 halted: halting machine.\n");
machine_halt();
break; /* not reached */
}
case SHUTDOWN_crash:
{
The call to debugger_trap_immediate is just an int3, which is handled in
arch/x86_traps.c by do_int3(), which looks like this:
asmlinkage int do_int3(struct cpu_user_regs *regs)
{
struct vcpu *v = current;
struct trap_bounce *tb = &v->arch.trap_bounce;
struct trap_info *ti;
DEBUGGER_trap_entry(TRAP_int3, regs);
if ( !guest_mode(regs) )
{
DEBUGGER_trap_fatal(TRAP_int3, regs);
show_execution_state(regs);
panic("CPU%d FATAL TRAP: vector = 3 (Int3)\n", smp_processor_id());
}
But because the dom0 has gone away, we are not in guest mode anymore, and so we
hit the panic. The panic is handled in drivers/char/console.c, which has
another call to debugger_trap_immediate, which generates the int3, which gets
us into the infinite loop. Reverting the change noted above goes back to the
old behavior (i.e. actually rebooting :). I'm tempted to say the
debugger_trap_immediate has no business being in the panic function, but I'd
like to hear other opinions on it.
Chris Lalancette
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home