On 04/25/2012 04:44 PM, Benjamin Herrenschmidt wrote:
Do we know what the bad interrupt maps to ? Also what is the value of
NR_IRQ and do you have SPARSE_IRQ enabled ? Can you try with the latter
disabled and NR_IRQ set to something large, such as 128 ?
(You may be able to check the interrupt mapping in debugfs)
Sorry, I was unable to find anything in debugfs to help me learn about interrupt
mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried reducing
it to 128. The setting for CONFIG_SPARSE_IRQ was on, and changing it to off did
not make any difference.
I finished the bisection, which led to
commit a79dd5ae5a8f49688d65b89a859f2b98a7ee5538
Author: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Date: Thu Dec 15 11:13:03 2011 +1100
tty/serial/pmac_zilog: Fix suspend & resume
As this seemed to be an improbable result, I did the full test by checking out
the previous commit (43ca5d3). That resulted in a "good" result. Then I used
quilt to add commit a79dd5a as a patch and the fault returned. I then noticed
that you said in the commit message that "I removed some code for handling
unexpected interrupt which should never be hit...". It appears that my box does
indeed hit such an unexpected interrupt.
I could always get rid of the fault by disabling CONFIG_SERIAL_PMACZILOG, but I
would like to fix the problem if possible.
Thanks,
Larry
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
