Hi,
With 2.6.23-rc6 running on the ppc64 box, following oops is hit
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=128 pSeries
Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
Call Trace:
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- 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:
409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
Kernel panic - not syncing: Fatal exception in interrupt
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
NIP: c000000000026024 LR: c00000000004e378 CTR: 800000000013f270
REGS: c00000000ffef120 TRAP: 0700 Tainted: G D (2.6.23-rc6-autokern1)
MSR: 8000000000021032 <ME,IR,DR> CR: 22002022 XER: 0000000a
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000001 c00000000ffef3a0 c0000000006fe598 c00000000069ffb8
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000007
GPR08: 0000000000000000 c000000000739818 c000000000742998 c00000000069ffb8
GPR12: 0000000000004000 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 0000000000000007
GPR28: c0000000004e3190 0000000000000000 c000000000685b80 0000000000000000
NIP [c000000000026024] .smp_call_function_map+0x34/0x28c
LR [c00000000004e378] .panic+0x98/0x1b0
Call Trace:
[c00000000ffef3a0] [c0000000006943e8] 0xc0000000006943e8 (unreliable)
[c00000000ffef450] [c00000000004e378] .panic+0x98/0x1b0
[c00000000ffef4f0] [c00000000002213c] .die+0x224/0x264
[c00000000ffef590] [c0000000000231f0] .machine_check_exception+0x210/0x240
[c00000000ffef610] [c000000000003480] machine_check_common+0x100/0x180
--- Exception: 200 at .end_bio_bh_io_sync+0x5c/0xac
LR = .bio_endio+0xb4/0xd4
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- 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.
Hi Kamalesh,
There's two things at work here ...
On 9/14/07, Kamalesh Babulal <[email protected]> wrote:
> Hi,
>
> With 2.6.23-rc6 running on the ppc64 box, following oops is hit
>
> Oops: Machine check, sig: 7 [#1]
>
> SMP NR_CPUS=128 pSeries
>
> Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
>
> NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
>
> REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
>
> MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
>
> TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
>
> GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
>
> GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
>
> GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
>
> GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
>
> GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
>
> GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
>
> GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
>
> GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
>
> NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
>
> LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> Call Trace:
>
> [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
>
> [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
>
> [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
>
> [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
>
> [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
>
> [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
>
> [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
>
> [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
>
> [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
>
> [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
>
> [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
>
> [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
>
> [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
>
> [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
>
> --- 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:
>
> 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
>
> 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
>
> Kernel panic - not syncing: Fatal exception in interrupt
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
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:
> > With 2.6.23-rc6 running on the ppc64 box, following oops is hit
> >
> > Oops: Machine check, sig: 7 [#1]
> >
> > SMP NR_CPUS=128 pSeries
> >
> > Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
> >
> > NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
> >
> > REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
> >
> > MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
> >
> > TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
> >
> > GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
> >
> > GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
> >
> > GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
> >
> > GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
> >
> > GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
> >
> > GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
> >
> > GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
> >
> > GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
> >
> > NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
> >
> > LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > Call Trace:
> >
> > [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
> >
> > [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
> >
> > [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
> >
> > [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
> >
> > [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
> >
> > [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
> >
> > [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
> >
> > [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
> >
> > [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
> >
> > [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
> >
> > [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
> >
> > [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
> >
> > [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
> >
> > [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
> >
> > --- 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:
> >
> > 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
> >
> > 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
> >
> > Kernel panic - not syncing: Fatal exception in interrupt
>
> 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 <[email protected]>
---
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(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 1ea4316..b24dcba 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -152,11 +152,6 @@ static void stop_this_cpu(void *dummy)
;
}
-void smp_send_stop(void)
-{
- smp_call_function(stop_this_cpu, NULL, 1, 0);
-}
-
/*
* Structure and data for smp_call_function(). This is designed to minimise
* static memory requirements. It also looks cleaner.
@@ -198,9 +193,6 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
int cpu;
u64 timeout;
- /* Can deadlock when called with interrupts disabled */
- WARN_ON(irqs_disabled());
-
if (unlikely(smp_ops == NULL))
return ret;
@@ -270,10 +262,19 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
return ret;
}
+static int __smp_call_function(void (*func)(void *info), void *info,
+ int nonatomic, int wait)
+{
+ return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
+}
+
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
int wait)
{
- return smp_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, int
cpumask_t map = CPU_MASK_NONE;
int ret = 0;
+ /* Can deadlock when called with interrupts disabled */
+ WARN_ON(irqs_disabled());
+
if (!cpu_online(cpu))
return -EINVAL;
@@ -299,6 +303,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
}
EXPORT_SYMBOL(smp_call_function_single);
+void smp_send_stop(void)
+{
+ __smp_call_function(stop_this_cpu, NULL, 1, 0);
+}
+
void smp_call_function_interrupt(void)
{
void (*func) (void *info);
On Tue, 18 Sep 2007, Satyam Sharma wrote:
>
> > ------------[ 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 (?)
On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
> 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 ***
On Mon, 17 Sep 2007 18:37:49 -0700
Randy Dunlap <[email protected]> wrote:
> On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
>
> > 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/
Crosstool is widely used. It'll build several combinations of
gcc/binutils/glibc for you.
http://www.kegel.com/crosstool/
There's also the ELDK from Denx:
http://www.denx.de/en/view/Software/WebHome#Embedded_Linux_Development_Kit
josh
> On Mon, 17 Sep 2007 18:37:49 -0700
> Randy Dunlap <[email protected]> wrote:
>
> > On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
> >
> > > 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:
--- cross-compilers/read-me.txt~powerpc64 2007-09-19 14:39:01.000000000 +0530
+++ cross-compilers/read-me.txt 2007-09-19 14:44:29.000000000 +0530
@@ -3,7 +3,7 @@ i386 cross-compilation binaries for seve
on RH FC5 and RH FC6 i386 and x86_64.
- untar the tarball in /
-- setenv ARCH sparc64 (or alpha, arm, i386, ia64, m68k, mips, s390, sparc)
+- setenv ARCH sparc64 (or alpha, arm, i386, ia64, m68k, mips, powerpc64, s390, sh4, sparc, x86_64)
- xb mrproper
- xb allmodconfig
- xb
--- cross-compilers/xb~powerpc64 2007-09-19 14:40:09.000000000 +0530
+++ cross-compilers/xb 2007-09-19 14:52:46.000000000 +0530
@@ -31,6 +31,7 @@ I=vmlinux
[ $ARCH = m68k ] && CT=gcc-4.1.0-glibc-2.3.6
[ $ARCH = mips ] && CT=gcc-3.4.5-glibc-2.3.6
[ $ARCH = powerpc ] && CT=gcc-4.1.0-glibc-2.3.6 && XARCH=powerpc-405-linux-gnu
+[ $ARCH = powerpc64 ] && CT=gcc-3.4.0-glibc-2.3.2 && export ARCH=powerpc
[ $ARCH = s390 ] && CT=gcc-4.1.0-glibc-2.3.6
[ $ARCH = sh ] && CT=gcc-3.4.5-glibc-2.3.6 && XARCH=sh4-unknown-linux-gnu
[ $ARCH = sparc ] && CT=gcc-4.1.0-glibc-2.3.6
On Mon, 17 Sep 2007, Josh Boyer wrote:
>
> Crosstool is widely used. It'll build several combinations of
> gcc/binutils/glibc for you.
>
> http://www.kegel.com/crosstool/
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 ...
On Wed, 19 Sep 2007 19:15:00 +0530 (IST) Satyam Sharma wrote:
>
> 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
Satyam Sharma wrote:
>> ------------[ 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 <[email protected]>
>
> ---
>
> 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(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 1ea4316..b24dcba 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -152,11 +152,6 @@ static void stop_this_cpu(void *dummy)
> ;
> }
>
> -void smp_send_stop(void)
> -{
> - smp_call_function(stop_this_cpu, NULL, 1, 0);
> -}
> -
> /*
> * Structure and data for smp_call_function(). This is designed to minimise
> * static memory requirements. It also looks cleaner.
> @@ -198,9 +193,6 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
> int cpu;
> u64 timeout;
>
> - /* Can deadlock when called with interrupts disabled */
> - WARN_ON(irqs_disabled());
> -
> if (unlikely(smp_ops == NULL))
> return ret;
>
> @@ -270,10 +262,19 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
> return ret;
> }
>
> +static int __smp_call_function(void (*func)(void *info), void *info,
> + int nonatomic, int wait)
> +{
> + return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
> +}
> +
> int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
> int wait)
> {
> - return smp_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, int
> cpumask_t map = CPU_MASK_NONE;
> int ret = 0;
>
> + /* Can deadlock when called with interrupts disabled */
> + WARN_ON(irqs_disabled());
> +
> if (!cpu_online(cpu))
> return -EINVAL;
>
> @@ -299,6 +303,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
> }
> EXPORT_SYMBOL(smp_call_function_single);
>
> +void smp_send_stop(void)
> +{
> + __smp_call_function(stop_this_cpu, NULL, 1, 0);
> +}
> +
> void smp_call_function_interrupt(void)
> {
> void (*func) (void *info);
>
Hi,
This patch solves the badness oops we get on the powerpc.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.