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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
