--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
LR = .pseries_dedicated_idle_sleep+0xd0/0x194
[c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
[c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
[c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
[c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
fba1ffe8 fbc1fff0 fbe1fff8 7c6b1b78 f8010010 f821ff51 7cdd3378 f8e10100
f9010108 880d01da 7c000074 7800d182 <0b000000> e922a500 3860ffff e8090000
I tired googling for similar bug and found two which where earlier reported one
at linuxppc-dev mailing list on 2.6.23-rc1 kernel
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039905.html
and other on 2.6.22-rc1 kernel
http://lkml.org/lkml/2007/5/22/390
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
This oops is the real bug here, but is that a machine check exception?
If so, it could be a hardware failure what you saw there instead, and not
really a kernel bug ...
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
This one is not the real issue at all -- it's just a sad problem in the powerpc
panic() -> smp_send_stop() -> smp_call_function() -> smp_call_function_map()
call chain. The thing is, smp_call_function() cannot be allowed from interrupt
disabled contexts, hence the WARN_ON() there. But panic() is a special case,
and so we must *not* complain when called from panic -- doing so will only
scroll away the real call trace / oops log from the screen (thankfully you had
a serial cable there?) and distract from the real bug, like what
happened here ...
The fix is to define an alternative __smp_call_function(), that calls into
smp_call_function_map(), and is itself called from
smp_call_function(), and then:
1. Use the inner __smp_call_function() in smp_send_stop(), and,
2. Move the WARN_ON() to the smp_call_function() wrapper instead.
I'd be back at my desk only by Tuesday, so don't expect a patch before then,
unless Paul fixes this up by himself before that.
Cheers,
Satyam
From: Andy Whitcroft <hidden> Date: 2007-09-14 11:04:23
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's. Of course that is _supposed_ to be fixed by this
time ...
I believe it was Paul who fixed up that one, and he is already copied.
-apw
On Fri, Sep 14, 2007 at 04:07:37PM +0530, Satyam Sharma wrote:
This oops is the real bug here, but is that a machine check exception?
If so, it could be a hardware failure what you saw there instead, and not
really a kernel bug ...
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
comes when smp_call_function_map() has been called with irqs disabled,
which is illegal. However, there is a special case, the panic() codepath,
when we do not want to warn about this -- warning at that time is pointless
anyway, and only serves to scroll away the *real* cause of the panic and
distracts from the real bug.
* So let's extract the WARN_ON() from smp_call_function_map() into all its
callers -- smp_call_function() and smp_call_function_single()
* Also, introduce another caller of smp_call_function_map(), namely
__smp_call_function() (and make smp_call_function() a wrapper over this)
which does *not* warn about disabled irqs
* Use this __smp_call_function() from the panic codepath's smp_send_stop()
We also end having to move code of smp_send_stop() below the definition
of __smp_call_function().
Signed-off-by: Satyam Sharma <redacted>
---
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
arch/powerpc/kernel/smp.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
@@ -198,9 +193,6 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,intcpu;u64timeout;-/* Can deadlock when called with interrupts disabled */-WARN_ON(irqs_disabled());-if(unlikely(smp_ops==NULL))returnret;
@@ -270,10 +262,19 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,returnret;}+staticint__smp_call_function(void(*func)(void*info),void*info,+intnonatomic,intwait)+{+returnsmp_call_function_map(func,info,nonatomic,wait,cpu_online_map);+}+intsmp_call_function(void(*func)(void*info),void*info,intnonatomic,intwait){-returnsmp_call_function_map(func,info,nonatomic,wait,cpu_online_map);+/* Can deadlock when called with interrupts disabled */+WARN_ON(irqs_disabled());++return__smp_call_function(func,info,nonatomic,wait);}EXPORT_SYMBOL(smp_call_function);
@@ -283,6 +284,9 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, intcpumask_tmap=CPU_MASK_NONE;intret=0;+/* Can deadlock when called with interrupts disabled */+WARN_ON(irqs_disabled());+if(!cpu_online(cpu))return-EINVAL;
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
comes when smp_call_function_map() has been called with irqs disabled,
which is illegal. However, there is a special case, the panic() codepath,
when we do not want to warn about this -- warning at that time is pointless
anyway, and only serves to scroll away the *real* cause of the panic and
distracts from the real bug.
BTW arch/ppc/ has same issue, but that's gonna be removed by next year
anyways, so I think there's no point making a patch for that (?)
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
OSDL had some, but those are gone now.
I downloaded all of them and still use them, although it would
be good to have some more recent versions of them.
I put the power* compiler tarballs here:
http://userweb.kernel.org/~rdunlap/cross-compilers/
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
OSDL had some, but those are gone now.
I downloaded all of them and still use them, although it would
be good to have some more recent versions of them.
I put the power* compiler tarballs here:
http://userweb.kernel.org/~rdunlap/cross-compilers/
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
OSDL had some, but those are gone now.
I downloaded all of them and still use them, although it would
be good to have some more recent versions of them.
I put the power* compiler tarballs here:
http://userweb.kernel.org/~rdunlap/cross-compilers/
Thanks -- BTW I made some simple changes to the tree structure in there
and added a few distcc [*] related scriptlets. The resulting tar ball:
http://www.cse.iitk.ac.in/users/ssatyam/powerpc64-unknown-linux-gnu.tar.bz2
can be made to work with Andrew's nice "xb" script with the following
trivial patch:
In fact, it turns out OSDL's cross-compiler toolchains were built with
crosstool itself. Should also add that those OSDL compilers are too old
(gcc version 3.4.x-3.5.x mostly -- my build was totally spammed with those
"+m" in asm constraints related warnings), so I'll try and build a few
more recent ones (at least for the more popular platforms) over the
weekend too.
Satyam
[*] But I'm a bit skeptical if the distcc stuff in "xb" works as intended.
Has anybody used that successfully? Will test it over the weekend ...
In fact, it turns out OSDL's cross-compiler toolchains were built with
crosstool itself. Should also add that those OSDL compilers are too old
(gcc version 3.4.x-3.5.x mostly -- my build was totally spammed with those
"+m" in asm constraints related warnings), so I'll try and build a few
more recent ones (at least for the more popular platforms) over the
weekend too.
Hi,
Please let us know if/when you have newer cross-compiler tarballs
available.
Thanks.
---
~Randy
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
comes when smp_call_function_map() has been called with irqs disabled,
which is illegal. However, there is a special case, the panic() codepath,
when we do not want to warn about this -- warning at that time is pointless
anyway, and only serves to scroll away the *real* cause of the panic and
distracts from the real bug.
* So let's extract the WARN_ON() from smp_call_function_map() into all its
callers -- smp_call_function() and smp_call_function_single()
* Also, introduce another caller of smp_call_function_map(), namely
__smp_call_function() (and make smp_call_function() a wrapper over this)
which does *not* warn about disabled irqs
* Use this __smp_call_function() from the panic codepath's smp_send_stop()
We also end having to move code of smp_send_stop() below the definition
of __smp_call_function().
Signed-off-by: Satyam Sharma <redacted>
---
Untested (not even compile-tested) patch.
Could someone point me to ppc32/64 cross-compilers for i386?
arch/powerpc/kernel/smp.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
@@ -198,9 +193,6 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,intcpu;u64timeout;-/* Can deadlock when called with interrupts disabled */-WARN_ON(irqs_disabled());-if(unlikely(smp_ops==NULL))returnret;
@@ -270,10 +262,19 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,returnret;}+staticint__smp_call_function(void(*func)(void*info),void*info,+intnonatomic,intwait)+{+returnsmp_call_function_map(func,info,nonatomic,wait,cpu_online_map);+}+intsmp_call_function(void(*func)(void*info),void*info,intnonatomic,intwait){-returnsmp_call_function_map(func,info,nonatomic,wait,cpu_online_map);+/* Can deadlock when called with interrupts disabled */+WARN_ON(irqs_disabled());++return__smp_call_function(func,info,nonatomic,wait);}EXPORT_SYMBOL(smp_call_function);
@@ -283,6 +284,9 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, intcpumask_tmap=CPU_MASK_NONE;intret=0;+/* Can deadlock when called with interrupts disabled */+WARN_ON(irqs_disabled());+if(!cpu_online(cpu))return-EINVAL;