Re: SATA resume slowness, e1000 MSI warning

Linus Torvalds
2007-03-06T16:57:08Z

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