libqmi-devel Digest, Vol 102, Issue 8

Tue May 26 13:13:21 UTC 2020

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>
wrote:

> Send libqmi-devel mailing list submissions to
>         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
>
> You can reach the person managing the list at
>         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>
> To: libqmi-devel at lists.freedesktop.org
> Subject: USB errors with qmi-wwan
> Message-ID:
>         <CAOCF0GO7xCyfRyTJmJnT=
> iZ9MoDCo6XL1Fa0YrOZz5GWm-+d3g 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
> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
> ------------------------------
>
> End of libqmi-devel Digest, Vol 102, Issue 8
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200526/05d0cec6/attachment.htm>