Foster, Doug F wrote:
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.
On an FTP would be usable, but if you can extract out key parts and post
them on the list, that might be better..
-----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
