]> err.no Git - linux-2.6/commitdiff
[PATCH] powerpc: clear IPIs on kdump
authorHaren Myneni <hbabu@us.ibm.com>
Thu, 6 Apr 2006 03:10:18 +0000 (21:10 -0600)
committerPaul Mackerras <paulus@samba.org>
Sat, 22 Apr 2006 08:45:01 +0000 (18:45 +1000)
In some crash scenarios, the kexec CPU is not responding to an IPI sent by
secondary CPU after init thread is forked, causing the system to drop into
xmon during kdump boot.  This problem can be reproduced each time when the
debugger is enabled and soft-reset is used to invoke kdump boot. The first
CPU sends an IPI - setting the IPI priority for all secondary cpus
(xics_cause_ipi()). But some CPUs will enter into the xmon via soft-reset,
i.e, not executing xics_ipi_action(). Hence, IPI is not cleared. When
exited from the debugger, one of these CPUs could become the primary kexec
CPU. Since the IPI is not cleared, causing this issue in kdump boot. This
patch clears and EOI IPI for kexec CPU as well before the kdump boot
started.

Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
arch/powerpc/platforms/pseries/xics.c

index 2d60ea30fed6a00d24efa99085070fbfe2492c16..6c17df5814b4b79d39be1460dfb5d0f6d244868b 100644 (file)
@@ -641,23 +641,26 @@ void xics_teardown_cpu(int secondary)
        ops->cppr_info(cpu, 0x00);
        iosync();
 
+       /* Clear IPI */
+       ops->qirr_info(cpu, 0xff);
+
+       /*
+        * we need to EOI the IPI if we got here from kexec down IPI
+        *
+        * probably need to check all the other interrupts too
+        * should we be flagging idle loop instead?
+        * or creating some task to be scheduled?
+        */
+       ops->xirr_info_set(cpu, XICS_IPI);
+
        /*
         * Some machines need to have at least one cpu in the GIQ,
         * so leave the master cpu in the group.
         */
-       if (secondary) {
-               /*
-                * we need to EOI the IPI if we got here from kexec down IPI
-                *
-                * probably need to check all the other interrupts too
-                * should we be flagging idle loop instead?
-                * or creating some task to be scheduled?
-                */
-               ops->xirr_info_set(cpu, XICS_IPI);
+       if (secondary)
                rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
                        (1UL << interrupt_server_size) - 1 -
                        default_distrib_server, 0);
-       }
 }
 
 #ifdef CONFIG_HOTPLUG_CPU