On Tue, 6 Mar 2007, Thomas Gleixner wrote: > > SATA has another nice feature. Somehow there is an interrupt pending on > the SATA controller, which comes in somewhere in the middle of resume. > If it happens before the SATA code resumed, the SATA code ignores the > interrupt and the interrupt is disabled due to "nobody cared", which in > turn prevents SATA to ever become functional again. Jeff - that sounds like a SATA bug. If you have an interrupt handler registered, you'd better handle the interrupt regardless of whether you think the hardware might be gone or not. It's generally *not* ok to do if (device_offline()) return IRQ_NONE; at the top of an interrupt handler. Of course, if you think the hardware is supposed to be quiescent, then the only thing you should do is generally just do the "shut up" operation (ie read status, write it back or whatever). You must generally *not* try to pass any data upwards (ie if the higher layers have told you to shut up, you may need to handle the hardware, but you must not involve the higher layers themselves any more, because they expect you to be quiet). And if you cannot do that because you need to resume in order to have the status register mapped, then you need to have an "early_resume()" function which gets called *before* interrupts are enabled. That's what early-resume (and late-suspend) are designed for: doing things that happen very early in the resume sequence before everything is up. And if you don't want to do any of these things (or are unable to, because of some ordering constraint or bad design), then you simply need to unregister and re-register the interrupt handler over sleep. > Any idea on that one ? Jeff, Auke, does this ring any bells? Linus
