https://bugzilla.kernel.org/show_bug.cgi?id=213081 --- Comment #25 from Mathias Nyman (mathias.nyman@xxxxxxxxxxxxxxx) --- Thanks, the trace gives a pretty good picture of what is going on. Before 5.12 the xhci driver handled halted endpoints (TRB completed with STALL) by immediately queuing both a reset endpoint command to clear the host side of the halted endpoint, and a "set TR dequeue" command to move past the Stalled TRB. In 5.12 the Reset endpoint command is queued first, and "set TR Dequeue" command is queued when the reset endpoint command completes, if needed. Traces show that hardware already moved past the stalled TRB when reset endpoint completed, so driver won't issue a "Set TR Dequeu" command at all. I think this command is anyway needed as it will also flush the TRB cache of xHC controller. >From traces: Stall on TRB at fffcb040: 56.024868: xhci_handle_event: EVENT: TRB 00000000fffcb040 status 'Stall Error' len 13 slot 5 ep 3 type 'Transfer Event' flags e:C Queue reset endpoint command: 56.024873: xhci_queue_trb: CMD: Reset Endpoint Command: ctx 0000000000000000 slot 5 ep 3 flags t:C When the reset endpoint command completes we see hardware dequeue is at fffcb050: 56.024970: xhci_handle_command: CMD: Reset Endpoint Command: ctx 0000000000000000 slot 5 ep 3 flags t:C 56.024971: xhci_handle_cmd_reset_ep: State stopped mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk IN burst 4 maxp 1024 deq 00000000fffcb051 avg trb len 0 No set TR Deq to move to fffcb050 is queued. I'll start working on a patch that forces a "Set TR dequeue" command after a stall -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
