Hello,
Justin Madru wrote:
>> Ah.. strange. The command protocol is ATAPI_PROT_NODATA and the drive
>> should be setting DRQ to receive CDB but it's not doing that.
>> Strange. It could be that the drive is a little bit tardy with DRQ -
>> ie. setting DRQ after clearing BUSY and ata_piix is now successfully
>> hitting the small window for some reason.
>>
>> Does the attached patch make any difference?
>>
>> Thanks.
>>
>>
> Ok, I applied your patch. Unfortunately, it didn't fix my problem.
> I now get a different, but similar message; not sure if it happens less
> frequently - still often though.
Aiee...
> What changes happened between .27 and .28 could've caused this?
> Anyways, below is what I get now (with your patch), including the
> frequency of occurrence.
I have no idea and I'm afraid we'll need a bisection here. :-( Can you
please try the attached patch?
Thanks.
--
tejun
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 4b47394..fcd7d08 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1120,6 +1120,22 @@ fsm_start:
*/
poll_next = (qc->tf.flags & ATA_TFLAG_POLLING);
+ {
+ int cnt = 0;
+
+ while (!(status & (ATA_DRQ | ATA_ERR | ATA_DF)) &&
+ cnt < 100) {
+ status = ap->ops->sff_check_status(ap);
+ cnt++;
+ udelay(10);
+ }
+
+ if (cnt)
+ ata_port_printk(ap, KERN_INFO,
+ "XXX status=%02x after %d tries\n",
+ status, cnt);
+ }
+
/* check device status */
if (unlikely((status & ATA_DRQ) == 0)) {
/* handle BSY=0, DRQ=0 as error */
