Hi, Felipe Balbi <felipe.ba...@linux.intel.com> writes: >>> I've been looking at this and based on sniffer and dwc3 tracepoints, it >>> seems like dwc3 is behaving properly. The real issue seems to be that >>> g_mass_storage isn't queueing a new request to IN endpoint. >>> >>> I'll continue debugging this and try to find a solution that doesn't >>> involve reverting $subject. >> >> oh no, wait. ep2out misses XferInProgress: >> >> file-storage-1592 [000] d..1 152.809922: dwc3_ep_queue: ep2out: req >> ffff88003cd6ee40 length 0/512 zsI ==> -115 >> file-storage-1592 [000] d..1 152.809931: dwc3_prepare_trb: ep2out: >> 3/8 trb ffff88003a196050 buf 000000002d5e4000 size 512 ctrl 00000819 >> (HlcS:sC:normal) >> file-storage-1592 [000] d..1 152.809942: dwc3_gadget_ep_cmd: ep2out: >> cmd 'Update Transfer' [262151] params 00000000 00000000 00000000 --> status: >> Successful >> file-storage-1592 [000] .... 152.809951: usb_ep_queue: ep2out: length >> 0/512 sgs 0/0 stream 0 zsI status -115 --> 0 >> irq/34-dwc3-1593 [001] d..1 152.810212: dwc3_event: event >> (0000c040): ep0out: Transfer Complete [Setup Phase] >> irq/34-dwc3-1593 [001] d..1 152.810218: dwc3_ctrl_req: bRequestType >> 02 bRequest 01 wValue 0000 wIndex 0002 wLength 0 >> irq/34-dwc3-1593 [001] d..1 152.810228: __dwc3_gadget_ep_set_halt: >> ep2out: NOT stalled >> >> Sniffer shows me this completing, but I don't see IRQ for this. > > BTW, I just tested without $subject and it fails the same way. This is > caused by something else. Can you rerun your bisect while I look at the > problem here?
Okay, found it. This is caused by the ep_dequeue bug that I already fixed. see [1] for that [1] https://marc.info/?i=20170217105759.24356-1-felipe.ba...@linux.intel.com -- balbi
signature.asc
Description: PGP signature
