Mark Lord wrote: >>>> Ah.. one more thing, is this draining also needed after DMA commands or >>>> only after PIO commands? >> >> My drive doesn't do IDENTIFY_DMA, so I fed it a READ_DMA instead >> with "no data", and libata recovered without draining. > > More specifically, here's what happens for READ_DMA(1 sector) > with "NON_DATA" specified (same circustances as the failed IDENTIFY): > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata1.00: cmd c8/00:01:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0 > res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) > ata1: port is slow to respond, please be patient (Status 0xd0) > ata1: port failed to respond (30 secs, Status 0xd0) > ata1: soft resetting port > ATA: abnormal status 0xD0 on port 0x000101f7 > ATA: abnormal status 0xD0 on port 0x000101f7 > ata1.00: configured for UDMA/100 > ata1: EH complete > SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't > support DPO or FUA > > So no draining, and all is well again. > Odds look pretty good that this is just a PIO thing. So, this is specific to SATA (the host side at least) piix && PIO READ, right? I think we can fit this code nicely into piix_sata_error_handler() if we make sure that it triggers under the right condition - after a PIO READ command fails due to HSM violation caused by stuck DRQ. Can you please perform similar test on a native PATA device connected to native PATA controller? I'm curious whether SRST makes real silicons forget about the on-going command. 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
