* [PATCH] conditionalize call from panic() to smp_send_stop()
@ 2009-01-14 12:25 Jan Beulich
2009-01-15 3:34 ` Andi Kleen
0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2009-01-14 12:25 UTC (permalink / raw)
To: linux-kernel
... avoiding nested warnings and/or oopses as much as possible (namely
durin early boot).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
kernel/panic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.29-rc1/kernel/panic.c 2009-01-14 11:36:29.000000000 +0100
+++ 2.6.29-rc1-panic-conditional-stop/kernel/panic.c 2009-01-06 17:02:49.000000000 +0100
@@ -89,7 +89,8 @@ NORET_TYPE void panic(const char * fmt,
* unfortunately means it may not be hardened to work in a panic
* situation.
*/
- smp_send_stop();
+ if (num_online_cpus() > 1)
+ smp_send_stop();
#endif
atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] conditionalize call from panic() to smp_send_stop()
2009-01-14 12:25 [PATCH] conditionalize call from panic() to smp_send_stop() Jan Beulich
@ 2009-01-15 3:34 ` Andi Kleen
2009-01-15 9:16 ` Jan Beulich
0 siblings, 1 reply; 3+ messages in thread
From: Andi Kleen @ 2009-01-15 3:34 UTC (permalink / raw)
To: Jan Beulich; +Cc: linux-kernel
"Jan Beulich" <jbeulich@novell.com> writes:
> ... avoiding nested warnings and/or oopses as much as possible (namely
> durin early boot).
Better would be to fix smp_send_stop than to work around it for this
very limited case. I've been running into this with machine checks
too. The new fancy smp_call_function() that is there now just doesn't
work in any unusual situation like early boot or fatal exceptions,
My thinking was to use a separate vector, or possible just the NMI.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] conditionalize call from panic() to smp_send_stop()
2009-01-15 3:34 ` Andi Kleen
@ 2009-01-15 9:16 ` Jan Beulich
0 siblings, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2009-01-15 9:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
>>> Andi Kleen <andi@firstfloor.org> 15.01.09 04:34 >>>
>"Jan Beulich" <jbeulich@novell.com> writes:
>
>> ... avoiding nested warnings and/or oopses as much as possible (namely
>> durin early boot).
>
>Better would be to fix smp_send_stop than to work around it for this
>very limited case. I've been running into this with machine checks
>too. The new fancy smp_call_function() that is there now just doesn't
>work in any unusual situation like early boot or fatal exceptions,
Indeed - I wasn't used to smp_call_function...() to be generic functions
that can be fixed for all architectures at once. I simply wanted to avoid
needing individual changes in all architectures...
Jan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-01-15 9:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-14 12:25 [PATCH] conditionalize call from panic() to smp_send_stop() Jan Beulich
2009-01-15 3:34 ` Andi Kleen
2009-01-15 9:16 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.