On Wed, Apr 11, 2012 at 09:03:19PM -0400, David Miller wrote:

From: "Paul E. McKenney" <redacted>
Date: Wed, 11 Apr 2012 17:45:07 -0700

quoted

On Wed, Apr 11, 2012 at 08:18:54PM -0400, David Miller wrote:

quoted

From: Stephen Hemminger <redacted>
Date: Wed, 11 Apr 2012 17:10:04 -0700

quoted

On Wed, 11 Apr 2012 16:08:37 -0700
"Paul E. McKenney" [off-list ref] wrote:

quoted

Hmmm...  What CPU family is this running on?  From the look of the
stack, it is sneaking out of idle into softirq without telling RCU.
This would cause RCU to complain bitterly about being invoked from
the idle loop -- and RCU ignores CPUs in the idle loop.

							Thanx, Paul

Sun4... Ping David.

So is there anything specific I need to do in the sparc64
idle loop?

Hmmm...  I must confess that I don't immediately see how control
is passing from cpu_idle() in arch/sparc/kernel/process_64.c to
__handle_softirq().

But it looks like a simple function call in the call trace:

It's coming from the trap return code path at the end of hardware
interrupt processing, on the IRQ stack.

Ah!  I should have guessed something like that was happening given
that __handle_softirq() is written in assembly.

							Thanx, Paul