Skip to contentSkip to conversation

powerpc: EOI and clear IPI fix in xics_teardown_cpu()

PATCH In review Haren Myneni 2 participants 4 messages Jul 9, 2006 PowerPC

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 powerpc: EOI and clear IPI fix in xics_teardown_cpu()

If OK, please sent this patch to upstream.

Thanks
Haren

When invoked kdump boot, plpar_eoi() call is getting failed and calling panic().

Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000000

The issue is with the desc->chip->eoi(XICS_IPI) in xics_teardown_cpu(). Instead of passing the virq to desc->chip->eoi(), XICS_IPI is used. Also, clear IPI in xics_teardown_cpu() got removed recently (in 2.6.17-git25). Noticed in some crash dump cases (Ex: initiate kdump boot using soft-reset and xmon is enabled), IPI is not cleared for some CPU(s) before starting the kdump boot. Hence, causing the kdump boot failure.

arch/powerpc/platforms/pseries/xics.c renamed from arch/powerpc/platforms/pseries/xics.c.orig +9 -1
@@ -783,6 +783,14 @@ void xics_teardown_cpu(int secondary)
 	xics_set_cpu_priority(cpu, 0);
 
 	/*
+	 * Clear IPI
+	 */
+	if (firmware_has_feature(FW_FEATURE_LPAR))
+		lpar_qirr_info(cpu, 0xff);
+	else
+		direct_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
@@ -795,7 +803,7 @@ void xics_teardown_cpu(int secondary)
 		return;
 	desc = get_irq_desc(ipi);
 	if (desc->chip && desc->chip->eoi)
-		desc->chip->eoi(XICS_IPI);
+		desc->chip->eoi(ipi);
 
 	/*
 	 * Some machines need to have at least one cpu in the GIQ,
#1 lore raw
Quoted 9 lines · Haren Myneni

If OK, please sent this patch to upstream.

Thanks
Haren

When invoked kdump boot, plpar_eoi() call is getting failed and calling panic().

Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000000
Quoted 7 lines

The issue is with the desc->chip->eoi(XICS_IPI) in xics_teardown_cpu(). Instead of passing the virq to desc->chip->eoi(), XICS_IPI is used. Also, clear IPI in xics_teardown_cpu() got removed recently (in 2.6.17-git25). Noticed in some crash dump cases (Ex: initiate kdump boot using soft-reset and xmon is enabled), IPI is not cleared for some CPU(s) before starting the kdump boot. Hence, causing the kdump boot failure.

It's already fixed in my latest patch that fixes some issues with the new irq rework. Hopefully, paul will send the patch upstream tomorrow after we had a chance to test it a bit more.

Cheers,
Ben

#2 lore raw
Quoted 15 lines · Benjamin Herrenschmidt
Quoted 11 lines · Haren Myneni

If OK, please sent this patch to upstream.

Thanks
Haren

When invoked kdump boot, plpar_eoi() call is getting failed and calling panic().

Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000000

The issue is with the desc->chip->eoi(XICS_IPI) in xics_teardown_cpu(). Instead of passing the virq to desc->chip->eoi(), XICS_IPI is used. Also, clear IPI in xics_teardown_cpu() got removed recently (in 2.6.17-git25). Noticed in some crash dump cases (Ex: initiate kdump boot using soft-reset and xmon is enabled), IPI is not cleared for some CPU(s) before starting the kdump boot. Hence, causing the kdump boot failure.

Quoted 9 lines

It's already fixed in my latest patch that fixes some issues with the new irq rework. Hopefully, paul will send the patch upstream tomorrow after we had a chance to test it a bit more.

Cheers,
Ben

Ok, Are you talking about the patch posted http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024350.html? Sorry, I did not notice it before I posted. Yes, it is fixed passing proper ipi value to desc->chip->eoi(). But, we also to need to clear IPI in xics_teardown_cpu().

Thanks
Haren

arch/powerpc/platforms/pseries/xics.c renamed from arch/powerpc/platforms/pseries/xics.c.orig +8 -0
@@ -783,6 +783,14 @@ void xics_teardown_cpu(int secondary)
 	xics_set_cpu_priority(cpu, 0);
 
 	/*
+	 * Clear IPI
+	 */
+	if (firmware_has_feature(FW_FEATURE_LPAR))
+		lpar_qirr_info(cpu, 0xff);
+	else
+		direct_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