"Rafael J. Wysocki" <rjw@xxxxxxx> writes: > On Monday 23 February 2009, Eric W. Biederman wrote: >> "Rafael J. Wysocki" <rjw@xxxxxxx> writes: >> >> >> I don't know where in the state machine this is getting called but >> >> I would suggest doing this before we shutdown cpus. >> > >> > This is the plan. In fact, I'm going to do this in the next patch after the >> > $subject one has been tested and found acceptable. >> >> Good to hear. Then let's please get a version of the irq disable that calls >> shutdown, so we can be certain we don't have hardware irqs in flight. >> >> For the drivers it should not matter for clean cpu shutdown it will. > > OK, I will. My apologies I was wrong. Calling shutdown is not safe. I just remembered that masking an ioapic from anywhere besides the irq handler can lock the ioapic state machine, and lead to non-recoverable interrupts. It is rare but I have seen it happen. I wanted to figure out how to migrate interrupts outside of interrupt context and this was what prevented me. A suspend/resume cycle might be enough of a reset to get the ioapic out of that state but I don't know. The only safe way on x86 to shutdown a level triggered ioapic irq outside of irq context is for the driver to program the hardware to not generate an irq. Therefore doing anything with the irqs at the point where we are suspending them is a formality, and perhaps simply code that ensures in-flight irqs don't make it past a certain point. I believe we just need to call disable() and print a big nasty warning if any irq comes in after the suspend stage. Eric _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
