On 01/22/2010 01:52 AM, Jeff Garzik wrote: >> 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. > > If a drive is in Bus-Idle, as I mentioned, then there is no active data > transfer. Oh, you meant reading status instead of altstatus? >> 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. > > Lost interrupts do not happen often, but they do happen. Google finds > plenty of examples. Yeap, but genuine timeouts seem to happen more commonly and shortening initial timeout would also work for non-SFF controllers, so I think it would be better to do that instead. >> 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. > > Does this ever happen when data transfer is active? AFAIK this happens > during probe or reset or set-xfer or bus-idle or some other auxiliary > moment in time. It usually does but there are other components too. A USB host in my x61s often causes IRQ storm after STR cycle. There also was a strange I2C device which shared IRQ line with ATA controller and killed the IRQ line when the system status changed. It's just that with shareable IRQs, there's no reason the kernel should be this vulnereable to these not-so-uncommon failure modes. 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
