From: Grant Likely <hidden> Date: 2012-10-18 22:44:45
On Thu, Oct 18, 2012 at 10:59 PM, Dennis Schridde [off-list ref] wrote:
Am Donnerstag, 18. Oktober 2012, 22:32:55 schrieb Grant Likely:
quoted
Unfortunately the debug messages don't show up in the console log by
default. Can you either send the output of 'dmesg' after booting, or
add "loglevel=8" to the kernel boot parameters?
Here you go.
I also see some lines like:
irq: no irq domain found for /axon@10000000000/plb5/pciex-utl@a00000a000004000
Is that also a problem?
[cc'ing linuxppc-dev]
Okay, so what is happening is that the function cbe_init_pm_irq() is
trying to set up hwirq numbers 0x7e, 0x17e, 0x27e and continuing up
every 0x100 to 0xff7e. This happens because that function is
calculating the hwirq number used for_each_node, and shifts the node
number up 8 bits to make up the upper bits of the hwirq number.
However, according the the header file, only '0' and '1' are actual
valid values for the upper bits.
CONFIG_NODES_SHIFT = 8 for PowerPC 64, which accounts for the range 0..0xff.
arch/powerpc/platforms/cell/interrupt.h defines the values of
IIC_IRQ_NODE_SHIFT = 8 and IIC_IRQ_NODE_MASK 0x100.
So, from the context, I assume the function is trying to set up a PM
interrupt for each CPU in the Cell processor; and that there are 2 of
them. for_each_node() knows nothing of this and dutifully tries to set
up the irq for 256 processors; way beyond what is valid for the irq
controller.
Also, it should be noted that the irq does actually get set up by
irqdomain.c, but because everything above 0x1ff is larger than the
lookup table, it complains. The new code complains loudly (as you
discovered) if someone tries to use a hwirq larger than the map where
the old code didn't.
Looks to me like the fix is to change for_each_node() to something as
simple as "for (i = 0; i < 2; i++)"
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
From: Grant Likely <hidden> Date: 2012-10-18 22:59:50
On Thu, Oct 18, 2012 at 11:44 PM, Grant Likely
[off-list ref] wrote:
On Thu, Oct 18, 2012 at 10:59 PM, Dennis Schridde [off-list ref] wrote:
quoted
Am Donnerstag, 18. Oktober 2012, 22:32:55 schrieb Grant Likely:
quoted
Unfortunately the debug messages don't show up in the console log by
default. Can you either send the output of 'dmesg' after booting, or
add "loglevel=8" to the kernel boot parameters?
Here you go.
I also see some lines like:
irq: no irq domain found for /axon@10000000000/plb5/pciex-utl@a00000a000004000
Is that also a problem?
[cc'ing linuxppc-dev]
Okay, so what is happening is that the function cbe_init_pm_irq() is
trying to set up hwirq numbers 0x7e, 0x17e, 0x27e and continuing up
every 0x100 to 0xff7e. This happens because that function is
calculating the hwirq number used for_each_node, and shifts the node
number up 8 bits to make up the upper bits of the hwirq number.
However, according the the header file, only '0' and '1' are actual
valid values for the upper bits.
CONFIG_NODES_SHIFT = 8 for PowerPC 64, which accounts for the range 0..0xff.
arch/powerpc/platforms/cell/interrupt.h defines the values of
IIC_IRQ_NODE_SHIFT = 8 and IIC_IRQ_NODE_MASK 0x100.
So, from the context, I assume the function is trying to set up a PM
interrupt for each CPU in the Cell processor; and that there are 2 of
them. for_each_node() knows nothing of this and dutifully tries to set
up the irq for 256 processors; way beyond what is valid for the irq
controller.
Also, it should be noted that the irq does actually get set up by
irqdomain.c, but because everything above 0x1ff is larger than the
lookup table, it complains. The new code complains loudly (as you
discovered) if someone tries to use a hwirq larger than the map where
the old code didn't.
Looks to me like the fix is to change for_each_node() to something as
simple as "for (i = 0; i < 2; i++)"
As for the next failure seen in that log, it would appear that the
MPIC ->map hook, mpic_host_map(), is failing on some mappings, but it
does appear that it has some legitimate reasons for doing so. The
difference now is that I changed irqdomain code to complain about it.
That is probably an overreach, or at least it should be yelling quite
so much about it.
g.
From: Grant Likely <hidden> Date: 2012-10-18 23:18:17
On Thu, Oct 18, 2012 at 11:59 PM, Grant Likely
[off-list ref] wrote:
On Thu, Oct 18, 2012 at 11:44 PM, Grant Likely
[off-list ref] wrote:
quoted
On Thu, Oct 18, 2012 at 10:59 PM, Dennis Schridde [off-list ref] wrote:
quoted
Am Donnerstag, 18. Oktober 2012, 22:32:55 schrieb Grant Likely:
quoted
Unfortunately the debug messages don't show up in the console log by
default. Can you either send the output of 'dmesg' after booting, or
add "loglevel=8" to the kernel boot parameters?
Here you go.
I also see some lines like:
irq: no irq domain found for /axon@10000000000/plb5/pciex-utl@a00000a000004000
Is that also a problem?
[cc'ing linuxppc-dev]
Okay, so what is happening is that the function cbe_init_pm_irq() is
trying to set up hwirq numbers 0x7e, 0x17e, 0x27e and continuing up
every 0x100 to 0xff7e. This happens because that function is
calculating the hwirq number used for_each_node, and shifts the node
number up 8 bits to make up the upper bits of the hwirq number.
However, according the the header file, only '0' and '1' are actual
valid values for the upper bits.
CONFIG_NODES_SHIFT = 8 for PowerPC 64, which accounts for the range 0..0xff.
arch/powerpc/platforms/cell/interrupt.h defines the values of
IIC_IRQ_NODE_SHIFT = 8 and IIC_IRQ_NODE_MASK 0x100.
So, from the context, I assume the function is trying to set up a PM
interrupt for each CPU in the Cell processor; and that there are 2 of
them. for_each_node() knows nothing of this and dutifully tries to set
up the irq for 256 processors; way beyond what is valid for the irq
controller.
Also, it should be noted that the irq does actually get set up by
irqdomain.c, but because everything above 0x1ff is larger than the
lookup table, it complains. The new code complains loudly (as you
discovered) if someone tries to use a hwirq larger than the map where
the old code didn't.
Looks to me like the fix is to change for_each_node() to something as
simple as "for (i = 0; i < 2; i++)"
As for the next failure seen in that log, it would appear that the
MPIC ->map hook, mpic_host_map(), is failing on some mappings, but it
does appear that it has some legitimate reasons for doing so. The
difference now is that I changed irqdomain code to complain about it.
That is probably an overreach, or at least it should be yelling quite
so much about it.
What does the boot log look like with the attached patch? (compiled
only, I haven't booted with it)
g.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-10-18 23:26:26
On Thu, 2012-10-18 at 23:44 +0100, Grant Likely wrote:
Also, it should be noted that the irq does actually get set up by
irqdomain.c, but because everything above 0x1ff is larger than the
lookup table, it complains. The new code complains loudly (as you
discovered) if someone tries to use a hwirq larger than the map where
the old code didn't.
Looks to me like the fix is to change for_each_node() to something as
simple as "for (i = 0; i < 2; i++)"
I think somebody was expecting for_each_node() to iterate only present
nodes or something ... Not all Cell systems have both nodes btw, so we
might want to be a tiny bit smarter than that .... or not :-)
Cheers,
Ben.
From: Dennis Schridde <hidden> Date: 2012-12-24 13:52:21
Am Donnerstag, 15. November 2012, 17:58:35 schrieb Grant Likely:
Anyway, here is a real patch.
Thanks a lot, Grant!
Your patch improves the situation significantly. However, it is still not
entirely fixed:
irq: irq-93==>hwirq-0x5d mapping failed: -22
There are a lot less error messages than before, though. Please see attached
log.
Best regards,
Dennis Schridde
From: Dennis Schridde <hidden> Date: 2013-04-21 12:32:01
Hello all of you!
Am Donnerstag, 15. November 2012, 17:58:35 schrieb Grant Likely:
Umm, no. Some suggestions were made so I assumed you'd try those.
Anyway, here is a real patch. Try this:
- for_each_node(node) {
+ for_each_online_node(node) {
I am running my 3.8.6 kernel with your patch now (will this be merged anytime
soon?), but I still get a bunch of irq mapping failed messages.
Examples:
[ 0.490734] irq: irq-93==>hwirq-0x5d mapping failed: -22
[ 22.016469] irq: no irq domain found for /axon@10000000000/plb5/pciex-
utl@a00000a000004000 !
Please see attached log.
In addition I see a weird issue: All programs run on CPU 0 (cores 0+1) only,
while CPU 1 (cores 2+3) is always idle. Could this have anything to do with
the IRQ issue, or shall I start a new thread/report for that?
Best regards,
Dennis