[BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202

[BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202

[Kamalesh Babulal]

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.

Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202

[Satyam Sharma]

Hi Kamalesh,

There's two things at work here ...


On 9/14/07, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> 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

Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202

[Andy Whitcroft]

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 ...

[PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Satyam Sharma]

> ------------[ 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 <satyam@infradead.org>

---

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);

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Satyam Sharma]

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 (?)

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Randy Dunlap]

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 ***

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Josh Boyer]

On Mon, 17 Sep 2007 18:37:49 -0700
Randy Dunlap <randy.dunlap@oracle.com> 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

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Satyam Sharma]

> On Mon, 17 Sep 2007 18:37:49 -0700
> Randy Dunlap <randy.dunlap@oracle.com> 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 ...

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Randy Dunlap]

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

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

[Kamalesh Babulal]

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 <satyam@infradead.org>
>
> ---
>
> 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.