I am attaching Quectel EC25-E module to an ebmbedded board, which hosts a yocto-based linux (kernel version 4.19.0-xilinx-v2019.2).
The kernel is configured to detect the module as a QMI_WWAN and registers it. I have cross-compiled quectel-CM for the board, and it is able to run, detecting the module and connection to the interne through it, registering a wwan interface.
But when I run an in-house application which transmits data on udp (rather high speed, in the range of 1 Mbps or so), every once in a while I get this error. (The wwan is registered and works afterwards)
What could be the cause of this error?
what is the application? Could you help to share more information about your test steps ? Just form the log you provide, it is hard to confirm the reason. It is better to debug module debug log to confirm it. You can email to support@quectel.com to get the tool to catch the module debug log. Thanks!
I mean what is in-house application. In order to confirm your issue, it is better to provide the whole test log of quectel-CM and your test log. You know just the above log cannot confirm the root reason. Thanks!
My program is some gstreamer application streaming RTP packets on the device. It’s log would include lots of unrelated data.
Would a pcap, or a debug log of the udpsrc connected to the device good enough for this to be found out?
Seems the runtime suspend feature matters. I think you can try ,
try 1, transmit "usbcore.autosuspend=-1 " to your kernel to disable
try 2, echo -1>/sys/bus/usb/devices/usbX/power/autosuspend_delay_ms to disable autosleep.
try 3, set supports_autosuspend = -1 in qmi_wwan_q.c
try 4 , disable the usb autosleep through echo on>/sys/bus/usb/devices/usb1/power/control.
This warning is expected once in a while if you push packets at a higher rate than the system as a whole, for host cpu to radio network, is able to handle. It looks a bit ugly because of the full stack trace, but it is merely a warning that the Linux network device was unable to push packets “fast enough” compared to some limit.
I have considered changing this value to eliminate the unnecessary warnings, but concluded that the current value is as good as any. Occasional timeouts cannot be completely avoided with a USB connected radio interface. There will always be situations where the modem is unable to transmit anything for a short period, for example due to intermittent interference or a handover failure or other radio problems we have to anticipate. The 5 seconds timeout is pretty much standard for all types of Linux network devices. But it’s quite a lot easier to hit for a radio adapter than for an ethernet adapter.