Alan Cox wrote: >> transmission failure as timeouts. Of course, if we're ticking the timer >> while the command is not in flight, that's a bug. If there are cases >> where 30 secs isn't enough, can you please point me to those reports? > > I have been, in bugzilla - the raid failure example where old IDE > eventually reports a media error while libata keeps timing out, > resetting, repeating. Maybe the difference is not in timeout but what the driver does after timeout happens. After timeout, libata ignores almost everything (it considers DMA error reported on BMDMA status) and resets the device while IDE thinks that IRQ might be lost and complete the command if the TF status register says so. It could be that the particular device doesn't raise IRQ on certain error conditions but updates TF registers. After timeout, IDE completes the command with the indicated error while libata ignores the status and resets the device. libata never touches TF register after timeout because some controllers lock up hard if TF register is read after certain error conditions (event the status register). -- 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
