[PATCH] stop debugger recursion when multiple resets caught.

linas at austin.ibm.com linas at austin.ibm.com
Sat Apr 17 08:22:06 EST 2004


Hi Anton,

Please apply the following patch to Ameslab.  It fixes one of the
most serious KDB problems at this time: incorrect handling of
recursive calls into the debugger from unexpected exceptions.

For example, hitting the little yellow button repeatedly is currently
causing all sorts of havoc in KDB, as are some other, more bizarre
circumstances.  This patch should fix these.

--linas

-------------- next part --------------
--- arch/ppc64/kdb/kdbasupport.c.orig	2004-04-16 16:15:17.000000000 -0500
+++ arch/ppc64/kdb/kdbasupport.c	2004-04-16 17:11:56.000000000 -0500
@@ -1789,7 +1789,7 @@ kdb_debugger(struct pt_regs *regs) {
 	} else { /* regs invalid */
 		kdb(KDB_REASON_SILENT,0,regs);
 	}
-	return 0;
+	return 1;
 }

 int
--- arch/ppc64/kernel/traps.c.orig	2004-04-16 16:20:16.000000000 -0500
+++ arch/ppc64/kernel/traps.c	2004-04-16 16:26:09.000000000 -0500
@@ -171,13 +171,26 @@ SystemResetException(struct pt_regs *reg
 #endif

 	if (!debugger(regs))
+	{
 		die("System Reset", regs, 0);

+		/* We should issue a shutdown or hard reset here. */
+	}
+
 	/* Must die if the interrupt is not recoverable */
-	if (!(regs->msr & MSR_RI))
+	if (!(regs->msr & MSR_RI)) {
 		panic("Unrecoverable System Reset");

-	/* What should we do here? We could issue a shutdown or hard reset. */
+		/* We should issue a shutdown or hard reset here. */
+	}
+
+	/* What should we do here? We might be tempted to issue a shutdown
+	 * or hard reset, but that would be wrong.  The reason we go here
+	 * is because er hit the little yellow button a bunch of times,
+	 * while already being in the debugger.  The debugger just wants
+	 * these events to go away, be ignored, and that is exactly what
+	 * we should do.  The user has other mechanisms for hard reboot,
+	 * if that's what they really wanted to do. */
 }

 #ifdef CONFIG_PPC_PSERIES


More information about the Linuxppc64-dev mailing list