Alan Cox wrote: >> while IDE thinks that IRQ might be lost and complete the command if the >> TF status register says so. > > For PATA at least that makes a lot of sense. It would probably make the > Promise driver a lot more stable too. Can you elaborate a bit? I don't really think completing a command after 30sec timeout contributes a lot to driver stability. >> 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. > > And loses the important information like media errors > >> 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). > > Should that not then be a per host flag ? Yeah, that would be the best. The problem is that there are several different kinds of timeouts and we don't know which controller locks up after which timeout and investigating them is really difficult. IMHO, losing media error information is much better than locking up a machine hard. We can start white listing known good controllers but I'm skeptical how much benefit it will bring. 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
