Eric W. Biederman wrote: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > >> And on the big gotcha's I have found one more I am tracking. >> >> I am seeing pci bridges with a NULL pointer for the subordinate bus. >> Earlier I had thought that this was a symptom of the double remove >> but I have been able to reproduce it without that. >> >> On just a little bit deeper investigation it looks like the cases >> are dying are all coming when the nested bridge reappears. >> >> Which is wrong on so many levels as I am toggle power to the outer >> slot, so the nested bridge should not even exist at that time. Ugh. >> More tracing to for me on that one. > > Ok. Got it. I was processing the interrupt for a device after it had > been hot removed but before the device state had disappeared. > > pcie_isr looks like it would be even worse in that situation. Looping forever > if pciehp_readw(ctrl, PCIE_EXPSLTA) always succeed sand returns 0xffff. > > That loop in there appears impossibly misguided. If the pending interrupt > values change after you have received the interrupt another instance > of the same interrupt should be pending so the loop should be completely > unnecessary. > For level-triggered interrupt, I think it's true. But for edge-triggered interrupt, I don't think it's true. I think only one interrupt is generated if the first hotplug event occurs and the second hotplug event occurs before clearing the status of first hotplug event. Thanks, Kenji Kaneshige -- 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
