Re: [libusb] Bulk Transfers Timeout on AMD EPYC Computers

[Chris A. <chr...@sr...>]

I tried with an ASMedia ASM3142 based PCIe card. The behaviour is similar, except there are exactly 254 successful transfers every time and then they start failing. I get this message from dmesg:

[20047.573189] xhci_hcd 0000:68:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
[20047.573198] xhci_hcd 0000:68:00.0: Looking for event-dma 00000000fffc30b0 trb-start 00000000fffc4fb0 trb-end 0000000000000000 seg-start 00000000fffc4000 seg-end 00000000fffc4ff0
[20047.573204] xhci_hcd 0000:68:00.0: Looking for event-dma 00000000fffc30b0 trb-start 00000000fffc3000 trb-end 00000000fffc3070 seg-start 00000000fffc3000 seg-end 00000000fffc3ff0
[20052.571651] xhci_hcd 0000:68:00.0: Cancel URB 00000000d0831cdb, dev 1, ep 0x81, starting at offset 0xfffc3040
[20052.571671] xhci_hcd 0000:68:00.0: // Ding dong!
[20052.571790] xhci_hcd 0000:68:00.0: Stopped on No-op or Link TRB for slot 8 ep 2
[20052.571837] xhci_hcd 0000:68:00.0: Removing canceled TD starting at 0xfffc3040 (dma) in stream 0 URB 00000000d0831cdb
[20052.571850] xhci_hcd 0000:68:00.0: xhci_giveback_invalidated_tds: Giveback cancelled URB 00000000d0831cdb TD
[20053.572166] xhci_hcd 0000:68:00.0: Cancel URB 000000004ef649ab, dev 1, ep 0x81, starting at offset 0xfffc3080
[20053.572188] xhci_hcd 0000:68:00.0: // Ding dong!
[20053.572308] xhci_hcd 0000:68:00.0: Stopped on No-op or Link TRB for slot 8 ep 2
[20053.572355] xhci_hcd 0000:68:00.0: Removing canceled TD starting at 0xfffc3080 (dma) in stream 0 URB 000000004ef649ab
[20053.572364] xhci_hcd 0000:68:00.0: xhci_giveback_invalidated_tds: Giveback cancelled URB 000000004ef649ab TD

This is very similar to this bug, but was fixed a long time ago: https://ubuntu-bugs.narkive.com/i6kgAbRA/bug-1667750-new-xhci-hcd-error-transfer-event-trb-dma-ptr-not-part-of-current-td-ep-index-2-comp

My kernel version is 5.15.0-76-generic on Ubuntu 20.04

Here is the output from LIBUSB_DEBUG=4 https://pastebin.com/S2MwkgQr

Behaviourally the ASM3142 and AMD's starship controller are the same, but I suspect that the cause is different since this looks like an xhci/linux issue? I would actually prefer to use the PCIE card anyway since the starship only has two ports exposed on this motherboard.

Chris

On 2023-07-25 21:45, Xiaofan Chen wrote:
> CAUTION: External mail. Do not click on links or open attachments you do not trust.
>
> On Wed, Jul 26, 2023 at 2:04 AM Chris Adams
> <chr...@sr...> wrote:
>> I messaged some time ago about an issue I was having with bulk end points
>> timing out (https://urldefense.com/v3/__https://sourceforge.net/p/libusb/mailman/message/37802472/__;!!Ibyq0D7xP3j_!sd3S7arcjamOn1akDVnoqignrsOfzrArOvPprQCM5mwh8g_mHgvoRM-BARa_cROBjHIoSuMRQfcFvRKz2-F72aFe3vR1$ ) I have
>> narrowed down the problem now and it is repeatable. For the test I use the Cypress
>> FX3 SDK (which essentially just wraps libusb) and run their example code
>> 09_cyusb_performance.cpp which uses the libusb asynchronous API to repeatedly
>> read from a bulk endpoint (cypress fx3 development board).
>>
>> Steps to reproduce:
>>
>> Start 09_cyusb_performance
>> In a separate terminal start stress-ng --hdd 2
>> After a few successful transfers LIBUSB_TIMEOUT errors start
>>
>> The error occurs with the latest version of libusb 1.0.26 and older versions (1.0.24). The device
>> can be recovered using libusb_device_reset but it happens again. I have tried long timeouts
>> of 20s and it does not make a difference.
>>
>> I have tried this on 3 Intel machines with no issues. But it happens consistently on the two
>> AMD EPYCs I have tried it on. The specs of the two machines I have tried it on:
>> ...
>> Where do I even start to solve this issue?
> I will say to post the debug log first. Then try libusb git to see if
> that makes any differences.
>
> This may be a Linux kernel issue as well. So after you post the debug
> log, you may also
> want to check out linux-usb devel mailing list.
>
>
> --
> Xiaofan
This e-mail is intended only for the named recipient(s) and may contain confidential, personal and/or health information (information which may be subject to legal restrictions on use, retention and/or disclosure).  No waiver of confidence is intended by virtue of communication via the internet.  Any review or distribution by anyone other than the person(s) for whom it was originally intended is strictly prohibited.  If you have received this e-mail in error, please contact the sender and destroy all copies.