Re: [PATCH #upstream 2/2] libata: implement spurious irq handling for SFF and apply it to piix

[Tejun Heo <tj@kernel.org>]

Hello,

On 01/21/2010 04:33 AM, Jeff Garzik wrote:
> Overall, as long as the drive is in Bus-Idle mode, it should be safe to
> go ahead and read Status, for pretty much every controller and drive.

Hmmm... I was a bit worried about the case Alan mentioned several
times where access to AltStatus while data transfer is going on can
lead to silent data corruption.

> I would make exception only for the new SATA FIS-based controllers,
> where we know that hitting Status is likely both pointless and wasteful,
> as well as being superfluous because the newer FIS-based controllers all
> have irq status registers.

FIS-based ones need their own interrupt handlers anyway so,
fortunately, things like irq_check callback isn't necessary to begin
with.  :-)

> Additionally, I think we should have a "fast-timeout" and
> "slow-timeout", whereby we check Status after a short period (5
> seconds?) to make sure we did not lose an interrupt.  If Status is !BSY,
> then we can proceed with handling qc success/failure immediately.

Does this happen often?  What I find more common is just plain
timeouts, so I think it would improve our exception latency if we
apply different timeouts for each trial.  ie. For the first RW try,
set the timeout to 7 secs.  For the second, 15 and then to 30.  This
wouldn't harm the correctness while allowing libata to react much
faster to transient failures.

Another thing is I can think of which can improve our robustness is
dynamic irqpoll support such that when screaming IRQ happens, IRQ
subsystem not only shuts down the IRQ line but also begins selectively
irqpolling it.

Thanks.

-- 
tejun