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 -- 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
