On 14.1.2024 16.06, Michał Pecio wrote:
Hi Mathias,
I found that the code which causes my problems was specifically added
by your commit d104d0152a97f ("xhci: fix isoc endpoint dequeue from
advancing too far on transaction error").
Reverting this change removes the disconnection spam on my two NEC
hosts (different boards but same 1033:0194 rev 03 chip IDs). I have no
other hosts available to try at this time.
It also resolves similar spam and subsequent stream lockup on one
particular pair of host adapter and device, which suffers intermittent
transaction errors for reasons currently unknown. With d104d0152a97f
reverted this device loses frames as expected but keeps going.
So this surely looks like the right thing to do with my NEC hosts, but
of course d104d0152a97f was done for a reason, which apparently is that
some (unspecified) other hosts really work differently.
Thanks for debugging this issue.
Most hosts trigger transaction error events for either every TRB as
xhci spec says, (xhci section 4.10.2) or only on the last TRB in a TD
which has the "interrupt on completion" IOC flag set.
If we revert d104d0152a97f and finish the td on the first error event
then we will get a similar "Transfer event TRB DMA ptr not part of current TD"
message for each remaing TRB in that TD that issues a error event.
So this case where only the fist TRB triggers an error event isn't yet
handled by the driver.
I'll take a look at it.
Can you try out some testpatches if I post them?
Thanks
Mathias
