MPC8572 PCIe error recovery

[Reifman, Boris]

We are using the MPC8572 running SMP Linux 2.6.23 kernel. Having
problems reliably recovering from core_fault_in which is generated by
the PCIe 2 Controller (RC) on reception of UR/CA messages. The PCIe
Controller has error detection and interrupts turned on in PEX_ERR_XX
registers.  Also, AER capability is enabled via controller configuration
space. The ISR handler which performs recovery action uses the following
epilog: if the ISR is running on the same core (0 or 1) from which the
failed PCIe transaction was made, it increments NIP by 4 and exits.  If
the core is different, the ISR sends an IPI message to the other core
which in its turn does all chores and then recovers the execution in a
similar way, i.e., it bumps NIP by 4 and exits.  The code works well
when running on core 0; however, the moment it switches to core 1, it
always generates a kernel paging error:

 

[   77.169436] Unable to handle kernel paging request for data at
address 0x00000080
[   77.176899] Faulting instruction address: 0xc0006d94
[   77.181850] Oops: Kernel access of bad area, sig: 11 [#1]

 

Anyone has any idea why Core 1 chokes on the code which Core 0 runs
flawlessly?  Is there a known problem with 2.6.23 kernel?  Should I be
concern with L1/L2 icache state?

 

Any pointers would be greatly appreciated!

 

Thanks in advance...

 

Boris Reifman | Principal Engineer P&T
breifman at ciena.com | 1185 Sanctuary Parkway, Suite 300 | Alpharetta, GA
30009 USA
Direct +1.678.867.3323 | Mobile +1.770.851.3440 | Fax +1.678.867.5101

 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090603/2e375ce1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3410 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090603/2e375ce1/attachment.gif>