libqmi-devel Digest, Vol 102, Issue 8

Wed May 27 03:06:30 UTC 2020

Hi Paul,

Does same problem occur with MBIM as well?

Amol

From: libqmi-devel <libqmi-devel-bounces at lists.freedesktop.org> On Behalf Of Paul Gildea
Sent: Tuesday, 26 May 2020 6:43 PM
To: libqmi (development) <libqmi-devel at lists.freedesktop.org>
Subject: Re: libqmi-devel Digest, Vol 102, Issue 8

Hi Geert,

I am seeing this -71 EPROTO error on two occasions. The one I am currently seeing is happening with Telit LN960A18's.
We pass traffic over the modem with iperf3 and it resets after a time period with those errors, usually within 30 minutes.
If I force the modem to USB2.0 it seems to not happen. I'm currently trying to find out why this is happening, I am looking at the
kernel debug and am seeing a "do warm reset" debug message from the driver (hub.c) and have been trying to track down why.

The second was covered in detail in another thread on here called "MTU issues", here was the finding:

Enabled traces for usbnet.c and xhci-ring.c file in debugfs as follows:
mount -t debugfs none /sys/kernel/debug
echo -n 'file usbnet.c +p' > /sys/kernel/debug/dynamic_debug/control
echo -n 'file xhci-ring.c +p' > /sys/kernel/debug/dynamic_debug/control
Saw a lot of errors indicating URB with len=0 when it was expecting len=1430. This was preceded by an URB of len 1024 bytes:
xhci_hcd 0000:00:14.0: Babble error for slot 10 ep 12 on endpoint
xhci_hcd 0000:00:14.0: Giveback URB ffff8802193be540, len = 1024, expected = 1430, status = -75
xhci_hcd 0000:00:14.0: Transfer error for slot 10 ep 12 on endpoint
/repeated
Error -75 is EOVERFLOW, which makes sense as per include/uapi/asm-generic/errno.h
#define EOVERFLOW 75 /* Value too large for defined data type */
"Babble error": When a packet larger than MTU arrives in Linux from the modem and is discarded with -EOVERFLOW error.
This is seen on USB3.0 and USB2.0 busses. This is essentially because the MRU (Max Receive Size) is not a separate entity to the MTU (Max Transmit Size) and the received packets can be larger than those transmitted.
"Endless input error": Following the babble error we see an endless supply of zero-length URBs which are rejected with -EPROTO (increasing the rx input error counter each time).
This is only seen on USB3.0. These continue to come ad infinitum until the modem is shutdown.
There appears to be a bug in the core USB handling code in Linux that doesn't deal well with network MTUs smaller than 1500 bytes. By default the dev->hard_mtu (the "real" MTU) is in lockstep with dev->rx_urb_size (essentially an MRU), and it's the latter that is causing trouble. This has nothing to do with the modems; the issue can be reproduced by getting a USB-Ethernet dongle, setting the MTU to 1430, and pinging with size greater than 1406.
Will submit the below patch that solves the issue, if that is acceptable?

+diff -Naur linux-4.14.73/drivers/net/usb/qmi_wwan.c linux-4.14.73-rx_size_fix/drivers/net/usb/qmi_wwan.c
+--- linux-4.14.73/drivers/net/usb/qmi_wwan.c 2018-09-29 11:06:07.000000000 +0100
++++ linux-4.14.73-rx_size_fix/drivers/net/usb/qmi_wwan.c 2020-01-31 18:05:07.709008785 +0000
+@@ -740,6 +740,14 @@
+ }
+ dev->net->netdev_ops = &qmi_wwan_netdev_ops;
+ dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
++
++ /* LTE Networks don't always respect their own MTU on receive side;
++ * e.g. AT&T pushes 1430 MTU but still allows 1500 byte packets from
++ * far-end network. Make receive buffer large enough to accommodate
++ * them, and add four bytes so MTU does not equal MRU on network
++ * with 1500 MTU otherwise usbnet_change_mtu() will change both.
++ * This is a sufficient max receive buffer as over 1500 MTU,
++ * USB driver issues are not seen.
++ */
++ dev->rx_urb_size = ETH_DATA_LEN + 4;
+ err:
+ return status;
+ }

I submitted this fix to the kernel but you just reminded me that it was rejected due to formatting and I completely forgot to resubmit.

--
Paul

On Tue, 26 May 2020 at 13:00, <libqmi-devel-request at lists.freedesktop.org<mailto:libqmi-devel-request at lists.freedesktop.org>> wrote:
Send libqmi-devel mailing list submissions to
        libqmi-devel at lists.freedesktop.org<mailto:libqmi-devel at lists.freedesktop.org>

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
or, via email, send a message with subject or body 'help' to
        libqmi-devel-request at lists.freedesktop.org<mailto:libqmi-devel-request at lists.freedesktop.org>

You can reach the person managing the list at
        libqmi-devel-owner at lists.freedesktop.org<mailto:libqmi-devel-owner at lists.freedesktop.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of libqmi-devel digest..."

Today's Topics:

   1. USB errors with qmi-wwan (Geert Lens)

----------------------------------------------------------------------

Message: 1
Date: Mon, 25 May 2020 15:42:56 +0200
From: Geert Lens <g.lens at livetech-systems.com<mailto:g.lens at livetech-systems.com>>
To: libqmi-devel at lists.freedesktop.org<mailto:libqmi-devel at lists.freedesktop.org>
Subject: USB errors with qmi-wwan
Message-ID:
        <CAOCF0GO7xCyfRyTJmJnT=iZ9MoDCo6XL1Fa0YrOZz5GWm-+d3g at mail.gmail.com<mailto:iZ9MoDCo6XL1Fa0YrOZz5GWm-%2Bd3g at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Hi,

We are using the QMI interface on the Quectel BG96 modem and everything
works fine, but after a few hours the connection is suddenly disconnected
and the qmi_proxy starts hogging CPU.

During this time the USB interfaces of the modem are not responding and
will only work again after the modem is physically turned off and on.

Output from dmesg:

*qmi_wwan 1-1:1.4: nonzero urb status received: -71*
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*

I have read that the -71 (EPROTO) is mostly caused by hardware or firmware
issues and that it can cause the kernel to disable the device, is
this correct? Or could it be something else?

Version used:
- Linux kernel: v4.14.78
- ModemManager: v1.12.10
- libqmi: v1.24.10

*Geert*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200525/c827d211/attachment-0001.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
libqmi-devel mailing list
libqmi-devel at lists.freedesktop.org<mailto:libqmi-devel at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/libqmi-devel

------------------------------

End of libqmi-devel Digest, Vol 102, Issue 8
********************************************
________________________________
The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200527/8fbcd234/attachment-0001.htm>