ata_sff_drain_fifo

[Pascal GREGIS]

Hello,

I have a question about the ata_sff_drain_fifo.
I saw it drains the fifo while the ATA_DRQ flag is on.
In my case, I sometimes get a stuck device and this drain is inefficient, trying to figure out why, I noticed the following :
   Jun 9 20:28:36 w11190100sav kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
   Jun 9 20:28:36 w11190100sav kernel: ata4.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
   Jun 9 20:28:36 w11190100sav kernel: res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
   Jun 9 20:28:43 w11190100sav kernel: ata4: port is slow to respond, please be patient (Status 0xd0)
   Jun 9 20:29:06 w11190100sav kernel: ata4: port failed to respond (30 secs, Status 0xd0)
   Jun 9 20:29:06 w11190100sav kernel: ata4: soft resetting port
   Jun 9 20:29:06 w11190100sav kernel: ATA: abnormal status 0xD0 on port 0x0001cc07
   Jun 9 20:29:06 w11190100sav last message repeated 4 times
   Jun 9 20:29:36 w11190100sav kernel: ata4.00: qc timeout (cmd 0xa1)
   Jun 9 20:29:36 w11190100sav kernel: ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
   Jun 9 20:29:36 w11190100sav kernel: ata4.00: revalidation failed (errno=-5)
   Jun 9 20:29:36 w11190100sav kernel: ata4: failed to recover some devices, retrying in 5 secs
   Jun 9 20:29:49 w11190100sav kernel: ata4: port is slow to respond, please be patient (Status 0xd0)

so the status is 0xD0.
In include/linux/ata.h I see :
	ATA_BUSY		= (1 << 7),	/* BSY status bit */
	...
	ATA_DRQ			= (1 << 3),	/* data request i/o */

so I guess when status is 0xD0, ATA_DRQ is not set but ATA_BUSY is.
It would explain why in my case it doesn't drain anything before trying to reset.

Would it be of any interest to drain the fifo also when the ATA_BUSY flag is on, not only the ATA_DRQ ?

Pascal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/