From: Haren Myneni <hbabu@us.ibm.com>
Date: Thu, 6 Apr 2006 03:10:18 +0000 (-0600)
Subject: [PATCH] powerpc: clear IPIs on kdump
X-Git-Tag: firefly_0821_release~35458^2~225^2~144
X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=81bbbe92949b069c101e13d3acbd4bc7d088cb79;p=firefly-linux-kernel-4.4.55.git

[PATCH] powerpc: clear IPIs on kdump

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>
---

diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 2d60ea30fed6..6c17df5814b4 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -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