ata_sff_drain_fifo

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

Re: ata_sff_drain_fifo

[Alan Cox]

> 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 ?

If the drive has the busy flag set it is busy, all we can do is wait for
it and if that fails try to reset it. The FIFO drain handles a specific
case where the two ends disagree about the amount of data expected, and
often lets us avoid a reset.

Alan

Re: ata_sff_drain_fifo

[Pascal GREGIS]

Alan Cox a écrit, le mer 18 aoû 2010 à 12:44:12 :
> > 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 ?
> 
> If the drive has the busy flag set it is busy, all we can do is wait for
> it and if that fails try to reset it. The FIFO drain handles a specific
> case where the two ends disagree about the amount of data expected, and
> often lets us avoid a reset.
Ok. I also noticed that qc->dma_dir=DMA_TO_DEVICE which also prevents the draining.
I thought it could be a solution for certain problems like mine where the device is busy but the reset doesn't work which brings to a blocking point, but no.

Pascal

> 
> Alan

Re: ata_sff_drain_fifo

[Alan Cox]

> Ok. I also noticed that qc->dma_dir=DMA_TO_DEVICE which also prevents the draining.
> I thought it could be a solution for certain problems like mine where the device is busy but the reset doesn't work which brings to a blocking point, but no.

It shouldn't unless there is a specific IDE controller need to drain
data. You could try it and see what it does but I doubt it will help -
but who knows 8)