Mark Lord wrote: > Jeff Garzik wrote: >> >> It's not really a good idea for SATA. The "FIFO" often co-emulated by >> the SATA controller and SATA phy. You just want to kick SATA really >> hard (i.e. bus reset and friends). > > Sure. So why don't we do that now? We do that. It's just that ata_piix is lacking SControl access so all we can do is SRST not PHY hardreset. I don't think draining FIFO/whatever on most SATA controllers would be unnecessary as PHY hardreset would make most drives forget what they were doing. I thought SRST would have similar effect. It's supposed to reset the device's HSM and thus clear DRQ, right? Stuck DRQ after SRST seems odd to me. One more thing to note is that there might be no way to drain data safely on non-SFF (ahci/sil24...) interfaces and some controllers lock the machine up hard when TF registers are accessed in certain unexpected way (unsurprisingly, sata_nv), so if we do this, it needs to be configurable per-driver. Another question is how would SATA controllers emulating TF interface react when data port is polled after a DMA command. I'm pretty sure many of them would behave erratically. Anyways, can you try to hack it into ata_bmdma_error_handler() and see whether it actually works? You can check for AC_ERR_HSM there and drain data port if DRQ is set. After HSM, ATA_NIEN is set and the port should be quiescent at that point. 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
