Re: libata bridge limits

[Tejun Heo <tj@kernel.org>]

Alan Cox wrote:
>>> Now we should probably have a shorter timeout where we then check the
>>> status bits for BUSY so we can quickly catch lost interrupts or commands
>>> but that is quite different.
>> Yeah, we need to check for lost interrupts and dead IRQ due to screaming
>> IRQ.  Maybe we can do some of that in interrupt core.
> 
> For SFF at least we can read altstatus and check for BUSY. If BUSY is not
> set then something is up, either we have an error we didn't get an IRQ
> for or the status is successful.
> 
>> The few I was talking about just freezes the whole machine after a
>> timeout.  Dunno whether the lowlevel driver needs to do EH differently
>> or the controller is just built that way tho.
> 
> Some lock the box solid if you don't reset the controller before you
> touch any registers on a timeout. I thought we had them all covered - do
> you know which controllers are still showing this ?

IIRC some very early via SATAs lock up the machine solid no matter what
you do unless a command is completed by the device side.  Maybe it
requires special sequence to abort in-flight commands but simple SRST
wasn't enough.  :-(

-- 
tejun