Messages in this thread |  | | | Date | Mon, 16 Feb 2009 17:02:20 +0900 | | From | Kenji Kaneshige <> | | Subject | Re: [PATCH] pciehp: Handle interrupts that happen during initialization. |
| |
Eric W. Biederman wrote: > ebiederm@xmission.com (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
|  |