PROBLEM: Linux 3.6.2 fails to boot on IBM Cell

[Grant Likely]

On Thu, Oct 18, 2012 at 11:59 PM, Grant Likely
<grant.likely at secretlab.ca> wrote:
> On Thu, Oct 18, 2012 at 11:44 PM, Grant Likely
> <grant.likely at secretlab.ca> wrote:
>> On Thu, Oct 18, 2012 at 10:59 PM, Dennis Schridde <devurandom at 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 at 10000000000/plb5/pciex-utl at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shut-up-irqdomain.patch
Type: application/octet-stream
Size: 1071 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20121019/c0954b54/attachment.obj>