Hi, On Wed, Sep 24, 2014 at 11:20:31AM -0500, Felipe Balbi wrote: > > > > > Therefore stalling is appropriate. Why it causes it problem for your > > > > > system is a different matter. Is your UDC hardware capable of halting > > > > > bulk endpoints? > > > > > > > > yeah, that part is just fine; I also verified with my sniffer that bulk > > > > halt is happening as it should. The problem, however, is that after that > > > > halt condition happens, host (same board has xhci too, Linux 3.17-rc5) > > > > issues a reset recovery > > > > > > It shouldn't; there's no reason for it to do so. Unless something > > > else is going wrong on the host side. Have you tried capturing a > > > usbmon trace on the host? > > > > I'll capture usbmon and send here shortly. > > here it is... Interesting part starts at line 73 (114 on this email) > where the data transport received EPIPE (due to Stall). This time > however, I was eventually able to talk to the device and managed to > issue quite a few writes to it. 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 ? - 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
