On Tue, 8 Sep 2009, aditya uttam wrote: > Hi Alan, > > Thanks for your valuable information. We have looked into the UAS > revision-2 document and modified the code accordingly. Thanks for the > advice, as we had failed to notice it > > Please find the latest usbmon output after the modifications. The CDB > is 16 bytes and starts at 16th location. The TAG and Length filed are > big endian format. > > However, there is no luck. Still I am getting the same errors. > > Could you please suggest me, if I am missing any thing. There are still plenty of mistakes in the protocol data: In your COMMAND IU packet, the LENGTH field is wrong. According to Table 11 in the UAS document, LENGTH is supposed to be n-5 where n is the number of the last byte in the packet. Since your packet has 32 bytes, the last byte is number 31. Thus n = 31 and so n-5 = 26. But the trace shows that LENGTH was set to 10, not 26. In the device's READ READY IU, WRITE READY IU, and SENSE IU packets, byte 1 contains garbage. It is reserved and should contain 0. Also in these packets, the TAG field is in little-endian byte order but it should be in big-endian. In the SENSE IU packets, the LENGTH and SENSE DATA fields contain garbage instead of the correct values. The trace shows that the device sends SENSE IU packets for READ commands before the data has been transferred. This violates the rule in section 6.3.4 of the UAS document. Those problems are relatively unimportant. Your real problem is this: Before every COMMAND IU, you submit a request for a 4-byte READ or WRITE READY IU followed by a request for a 10-byte SENSE IU. This is wrong. First, it's wrong because a SENSE IU might contain more than 10 bytes. But more importantly, it's wrong because you don't know in what order the device is going to send the packets. Here's what can happen (the letters in parentheses serve to identify and match up the packets): Driver Device ------ ------ Queue 4-byte status request (A) Queue 10-byte status request (B) Send WRITE COMMAND IU (C) Queue 4-byte status request (D) Queue 10-byte status request (E) Send READ COMMAND IU (F) Receive WRITE COMMAND IU (C) Send 4-byte WRITE READY status IU (A) Receive READ COMMAND IU (F) Receive WRITE READY IU (A) Send WRITE data (G) Send 4-byte READ READY status IU (B) Receive READ READY IU (B) Receive WRITE data (G) Send 10-byte SENSE status IU for the WRITE (D) Receive SENSE IU (D) -- Babble! Send READ data (H) Receive READ data (H) Send 10-byte SENSE status IU for the READ (E) Receive SENSE IU (E) The device sends back the status packets in an order you didn't expect. It sends back two 4-byte status packets followed by two 10-byte packets. But your driver asked to receive 4 bytes, then 10 bytes, then 4 bytes, then 10 bytes. As a result, the third status packet (D) generates a Babble error because it is 10 bytes long and the computer expected to receive only 4 bytes. To solve this problem, each of your status request packets has to be long enough to receive the largest status the device can send. When you receive the packet, you have to look at the IU ID field to determine what sort of packet it really is. And you have to look at the TAG field to determine which command it applies to. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
