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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux