Hello,
since some time I am fighting against a problem with USB:
I have a Qualcomm radio module (in my case a Quectel RM520N-GL and
SIMCOM SIM8260G-M2)
connected to a Phytec Pollux board with an NXP i.MX8MP.
I started with Linux 6.6.23. It communicates with USB 3.x.
I build up an internet connection with this radio module. I connected a
Notebook (via Wifi, but external hardware converts to Ethernet).
First test setup was a bit difficult.
Radio Module <-> USB 3.x <-> Phytec Linux Board <-> Ethernet Tunnel <->
Raspberry Pi CM5 <-> Wifi <-> Windows Notebook
I opened Firefox, Youtube worked well, HD video over multiple hours with
no problem.
Then I opened Microsoft Teams instead and data transfer immediately
stalled. I had a ping running in parallel directly to radio module, this
also stalled.
With more testing I found out also Firefox and opening Twitch.tv stalled
the connection.
# lsusb -t
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class,
Driver=option, 5000M
|__ Port 1: Dev 2, If 1, Class=Vendor Specific Class,
Driver=option, 5000M
|__ Port 1: Dev 2, If 2, Class=Vendor Specific Class,
Driver=option, 5000M
|__ Port 1: Dev 2, If 3, Class=Vendor Specific Class,
Driver=option, 5000M
|__ Port 1: Dev 2, If 4, Class=Vendor Specific Class,
Driver=qmi_wwan, 5000M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_ncm, 5000M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_ncm, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
#
It is the Bus 05, Port 1, Dev 2 with multiple interface.
I found a newer Linux version 6.6.52. Same error occured.
When error occurs, I don't see anything in system logs (e.g. dmesg).
Instead of the Quectel radio module I took one from SIMCOM and same
problem occured.
I added my USB 2.0 analyzer (old Ellisys) and problem disappeared.
Unfortunately I have no USB 3.x analyzer.
I am still waiting for a original NXP board with an i.MX8MP, which seems
a 6.12.x kernel can be used and tested.
I found an errata for i.MX8MP: ERR050714 “USB: HOST Stream IN issue if
received short packet”, but it looks like I have no Stream IN in use...?
So perhaps something different.
For confirming, if it could be something i.MX8MP related, I today took a
Raspberry Pi Compute Module 5 (CM5).
Also ARM64, but else, I assume completely different USB 3 peripheral.
And surprise: I was able to reproduce the problem.
The Raspberry Pi uses:
Linux CM5 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian
1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux
I still can't decide which side makes the problem, or if it is just an
interop problem.
I saw the virtual channel, which is used for data transfer, uses a
wMaxPacketSize of 1024 Bytes (IN and OUT) and a wMaxBurst of 6 (OUT) and
2 (IN).
I already created traces by usbmon, which I can share.
I can also read out USB descriptor (lsusb -v) and share.
Qualcomm radio modules are widely used, due to high possible throughput,
I assume people are also using USB 3.x with it.
I am not sure yet, why the error occurs on my side and not just works...
Someone already heard from such an error? Is there perhaps some workaround?
Can I perhaps patch wMaxPacketSize or wMaxBurst done in Kernel, at least
only for test purposes?
Note beside:
I can query number of sent and received IP packets. I sent the pings (1
every second).
The ping does not display, that it receives an answer, after the hang
occured.
But the radio module tells 5 sent and 5 received packets, when querying
the statistics every 5 packets via QMI.
So I assume sending (Bulk OUT) is working, packet go to server and back
to radio module, but answer is not sent over USB from device to host.
Second perhaps interesting note:
It looks like the received radio module is keeping/storing the packets.
After a more or less long time (a few hours), all buffers are exhausted.
Then QMI commands are not answered anymore.
When doing some action (I saw it with opening the channel for AT
commands, or for creating log files),
it could happen that all kept packets are then sent in one go, so I get
QMI packet statistic a lot of time, all with increase of 5 packets,
in sum an amount of packets, which needed the hours the create.
The radio module seems also to be using Linux. Which version, I don't know.
What can I do/test next?
Try again on a AMD x64 controller? Perhaps with main/latest of Linux Kernel?
I thought about getting an i.MX95, but seems to be not yet available,
but Phytec has some engineering samples (?) on boards, but release notes
say: only USB 2 is working yet.
Can I enabled traces in USB kernel which could be helpful to narrow the
problem.
Sorry for the long description. I tested meanwhile a lot...
Best regards,
Martin
