On Thu, Oct 18, 2012 at 11:59 PM, Grant Likely <grant.lik...@secretlab.ca> wrote: > On Thu, Oct 18, 2012 at 11:44 PM, Grant Likely > <grant.lik...@secretlab.ca> wrote: >> On Thu, Oct 18, 2012 at 10:59 PM, Dennis Schridde <devuran...@gmx.net> wrote: >>> Am Donnerstag, 18. Oktober 2012, 22:32:55 schrieb Grant Likely: >>>> 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.
shut-up-irqdomain.patch
Description: Binary data
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
