tiejun.chen wrote:
> Scott Wood wrote:
>> On Wed, 13 Oct 2010 09:17:01 +0800
>> "tiejun.chen" <tiejun.c...@windriver.com> wrote:
>>
>>> Scott Wood wrote:
>>>> The crash is happening somewhere in mpic_set_irq_type():
>>> Agreed. That is just where I pointed out on my email replied for OOPS. To
>>> enable
>>> DBG to figure out 'src' and 'mpic->irq_count' from the file,
>>> arch/powerpc/sysdev/mpic.c, .
>>> ======
>>> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
>>> {
>>> ......
>>> if (src >= mpic->irq_count)
>>> return -EINVAL;
>>> ^
>>> I think this OOPS may be from here.
>> No, it's after that. His board code is using the mpic's "isu" remapping
>
> I means OOPS is *from* here. According to David's call trace,
> mpic_set_irq_type() is the last issued function. And that corresponding return
> value, R3, is '0xffffffea', -22, and also '-EINVAL'. If everything is OK, I
> think we should not be failed with returning '-EINVAL' here. Right? So I think
> we should dump 'src' (mpic_irq_to_hw(virq)) and 'mpic->irq_count'. Then figure
> out why 'src' >= 'mpic->irq_count'. I think this can make our debug life
> easier.
>
Certainly I'm missing something since I have no any real environment. So maybe
we can use gdb to track this panic as normal :)
# gdb vmlinux
(gdb) list *mpic_set_irq_type+0x188/
Tiejun
> Tiejun
>
>> mechanism, and the MSIs aren't covered, so those registers aren't
>> ioremapped.
>>
>> -Scott
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
