Yes, I would be glad to post the traces. Is there a preferred location? Otherwise, I can just post them to an Intel FTP server for download. -----Original Message----- From: Tejun Heo [mailto:tj@xxxxxxxxxx] Sent: Sunday, March 01, 2009 5:52 AM To: Robert Hancock Cc: Foster, Doug F; linux-ide@xxxxxxxxxxxxxxx Subject: Re: ATAPI question Hello, Robert Hancock wrote: >> Using a SATA analyzer, I find that on an INQUIRY (12h) ATAPI packet >> command, the device sets bit-6 (DRDY) and bit-4 (SERV) in the status >> register, and bits 0 (CoD) and 1 (IO) are set in the ATAPI Interrupt >> Reason Register (ATA Sector Count Register). After SERVICE is flagged >> by the ATAPI device (and not serviced), it doesn't respond properly >> from then on. > > Bit 4 isn't SERV in this context, it's DRQ. (It's only SERV when TCQ is > in use, which it isn't.) It looks like this is a READ CAPACITY command > that's being issued by PIO. DRQ means the device expects to transfer > data - either to receive the CDB or send the response. Presumably that > didn't happen for some reason. Are you sure about both the C/D and I/O > bits being 1? That would mean command transfer to the host, which > doesn't make any sense. > > You're saying that DRQ never gets cleared after the INQUIRY command? > It's possible the device wanted to transfer more data than the PRD table > had room for. Not sure what AHCI ends up doing in this case. I'm CCing > Tejun who might know more.. libata always prepares for extra space for draining so I doubt that. Any chance you can post the traces? -- 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
