On Wed, 24 Sep 2014, Felipe Balbi wrote: > so here's sequence of events so far: > > - Enumration goes fine > - Get Max Lun -> 0 (single lun) > - Inquiry -> Passed > - Test Unit Ready -> Failed > - Request Sense (Unit Attention) -> Passed > - Test Unit Ready -> Passed > - Mode Sense -> Stall of Data transport. > - Clear Endpoint Feature (HALT) EP1 IN > - After clear feature, a 16 bulk in completes. Shouldn't gadget > driver have cancelled that ?
No. The 16-byte transfer (which I presume was the response to the MODE SENSE) should have completed _before_ the halt feature was set. The UDC driver is buggy. > - Bus reset > > This remains for a few iterations. One thing is very interesting ... > > [ snip ] > > > ed2541c0 1239906485 S Bo:003:01 -115 31 = 55534243 1e000000 12000000 > > 80000603 00000012 00000000 00000000 000000 > > ed2541c0 1239906590 C Bo:003:01 0 31 > > > ec1a8740 1239906770 S Bi:003:01 -115 18 < > > ec1a8740 1239906871 C Bi:003:01 0 18 = 70000600 0000000a 00000000 29000000 > > 0000 > > ed2541c0 1239906975 S Bi:003:01 -115 13 < > > ed2541c0 1239907026 C Bi:003:01 0 13 = 55534253 1e000000 00000000 00 > > ed2541c0 1239907803 S Bo:003:01 -115 31 = 55534243 1f000000 00020000 > > 80000ca1 082e0001 00000000 ec000000 000000 > > 0xa1 ? What is this ? Looks like XHCI corrupted the packet ? I can see > the same SCSI opcode (0xa1) with my sniffer. 0xa1 is an ATA pass-through command. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
