Re: [PATCH] [RFC] xhci: Add Link TRB sync quirk for ASM3142

[Ole Salscheider <ole@salscheider.org>]

Hi Mathias.

On 16.04.21 14:09, Mathias Nyman wrote:
 > Hi Ole
 >
 > On 16.4.2021 12.37, Ole Salscheider wrote:
 >> This patch adds a quirk to the xhci driver so that link TRBs are only
 >> given to the host controller once it has processed all previous TRBs on
 >> this segment.
 >>
 >> This quirk is necessary for me on an ASMedia ASM3142 host controller.
 >> Without it, I get the following errors when accessing a SuperSpeed UVC
 >> camera:
 >>
 >> Transfer event TRB DMA ptr not part of current TD ep_index XX 
comp_code XX
 >>
 >> You can find more details in my previous mail about the problem:
 >> https://lkml.org/lkml/2021/3/31/355
 >>
 >> This patch fixes my problem, but it is probably terribly wrong. I am not
 >> even sure if I can rely on handle_tx_event being called before each link
 >> TRB in the segment. Some feedback would be very welcome.
 >
 > I think we need to look at the cause more closely.
 >
 > We normally only get events for the last TRB of a TD, or for short 
transfers like in your case.
 > So not every transfer TRB generates events.
 >
 > There are several things going on here that combined could cause this.
 >
 > Last transfer TRB of a segment has some alignment requirements which 
  might not be handled in the isoc case.
 > The amount of untransferred data is large, (16388 bytes) so the TRB 
causing the short packet
 > could be far from the last TRB we expect the event on.
 > Due to new segment and link trb maybe the stored last_trb for this TD 
is just set wrong
 >
 > Anyway, more detailed traces together with dynamic debug show us more:
 >
 > mount -t debugfs none /sys/kernel/debug
 > echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
 > echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
 > echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
 > echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
 > < trigger the issue >
 > Send output of dmesg
 > Send content of /sys/kernel/debug/tracing/trace
 >
 > trace accumulates pretty fast so try to copy it as soon as the issue 
is seen.

I have uploaded the dmesg output to
https://stuff.salscheider.org/dmesg_out
and the trace to
https://stuff.salscheider.org/trace_out

With the trace enabled, I did not get the DMA errors. Maybe it slowed 
down the computer enough. But still the camera stream froze after ~3 frames.

The log contains a recording with ffmpeg that gave a few frames (at 
second 83), then some where it hung completely. Then I re-plugged the 
camera and got a few more frames (at second 179) before it hung again.

I hope this is helpful. If you need a different log please tell me.

Best regards,

Ole