From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Lalancette <clalance@redhat.com>
Subject: Infinite loop on reboot with 3.0.3 and crash_debug=y
Date: Tue, 03 Oct 2006 17:06:31 -0400
Message-ID: <4522D0D7.1070105@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

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