[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Infinite loop on reboot with 3.0.3 and crash_debug=y

     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)

    switch ( reason )
    case SHUTDOWN_poweroff:
        printk("Domain 0 halted: halting machine.\n");
        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);
        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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.