Xen devel - Oct 2006 - Infinite loop on reboot with 3.0.3 and crash_debug=y

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Oct 03, 2006 at 05:06:31PM -0400, Chris Lalancette wrote:
> 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.
Last time I checked, dom0 was pretty good about using the correct
SHUTDOWN_xxx flag to indicate whether this is a "planned" shutdown or
a panic. Calling into debugger_trap_immediate() may be fine for a
panic (assuming there''s a debugger there to avoid the infinite
loop...) but doesn''t make sense for planned shutdown. My .02 ILS.

Cheers,
Muli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 3/10/06 10:06 pm, "Chris Lalancette" <clalance@redhat.com>
wrote:
> 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.
There was previosuly special-case code for int3 in the debugger_trap macros.
I should add it back in. Also, Muli is correct that unconditional debugger
trap in dom0_shutdown is overkill.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel