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

[Ole Salscheider <ole@salscheider.org>]

Hi Mathias,

On 16.04.21 17:18, Ole Salscheider wrote:
> 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.

I tried it a second time today and now I got the DMA error also when 
tracing was active. You can find the dmesg and trace outputs here:

https://stuff.salscheider.org/dmesg_out2
https://stuff.salscheider.org/trace_out2

Best regards,

Ole