On Sat, Mar 16, 2013 at 2:14 AM, Richard Taylor <rjt-linux-pci@xxxxxxxxxxxxxxxxxxx> wrote: > Hi > > I am struggling with a badly behaved PCIe device that is either not > sending Read Completion packets or it is sending Unsupported Requests. > > My problem is that the affect of these is to leave the Non-Posted > transaction that is waiting for the Read Completion in a hung state, > consuming 100% CPU. > > I have read a number of times that when an error occurs it should be > possible to have the transaction return with 0xFFFFFFFF rather than hang. I'm not a hardware person, but I think this would be done by the Root Complex. I found a QorIQ P2020 Integrated Processor Reference Manual, rev 0 07/2009, and Table 16-125 seems to mention these cases in the first (no response) and third (UR response) rows. These show logging the error and sending an interrupt to the PIC. But the CPU probably won't recognize an interrupt until its read completes, so I doubt if the interrupt by itself helps. The table does mention sending all 1s (0xFFFFFFFF), but it looks like only for config transactions. So I agree; I would expect there would be a way to send 0xFFFFFFFF back to the CPU so it can continue, but I don't know how to make that happen. Doesn't the CPU have any kind of response timeout itself? I would think the CPU itself would eventually time out the read and take a machine check or something. I know that's not the response you're looking for, but at least it would keep the CPU from getting completely hung because of a broken peripheral. > I suspect this may be something to do with error severity or error > masking settings in the PCIe configuration registers. > > The CPU is a QoriQ P2020. > > Can anyone point me in the right direction for something to try? > > I have the AER driver installed and it shows error interrupts being > generated - but the memory read call still does not terminate. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
