<div dir="ltr">Hi Geert,<div> </div><div> </div><div>I am seeing this -71 EPROTO error on two occasions. The one I am currently seeing is happening with Telit LN960A18's. </div><div>We pass traffic over the modem with iperf3 and it resets after a time period with those errors, usually within 30 minutes.</div><div>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</div><div>kernel debug and am seeing a "do warm reset" debug message from the driver (hub.c) and have been trying to track down why.</div><div> </div><div>The second was covered in detail in another thread on here called "MTU issues", here was the finding:</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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; + }</blockquote><div> </div><div> </div><div>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.</div><div> </div><div>--</div><div>Paul </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 May 2020 at 13:00, <<a href="mailto:libqmi-devel-request@lists.freedesktop.org" target="_blank">libqmi-devel-request@lists.freedesktop.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send libqmi-devel mailing list submissions to <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a> To subscribe or unsubscribe via the World Wide Web, visit <a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a> or, via email, send a message with subject or body 'help' to <a href="mailto:libqmi-devel-request@lists.freedesktop.org" target="_blank">libqmi-devel-request@lists.freedesktop.org</a> You can reach the person managing the list at <a href="mailto:libqmi-devel-owner@lists.freedesktop.org" target="_blank">libqmi-devel-owner@lists.freedesktop.org</a> 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 <<a href="mailto:g.lens@livetech-systems.com" target="_blank">g.lens@livetech-systems.com</a>> To: <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a> Subject: USB errors with qmi-wwan Message-ID: <CAOCF0GO7xCyfRyTJmJnT=<a href="mailto:iZ9MoDCo6XL1Fa0YrOZz5GWm-%2Bd3g@mail.gmail.com" target="_blank">iZ9MoDCo6XL1Fa0YrOZz5GWm-+d3g@mail.gmail.com</a>> 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: <<a href="https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200525/c827d211/attachment-0001.htm" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200525/c827d211/attachment-0001.htm</a>> ------------------------------ Subject: Digest Footer _______________________________________________ libqmi-devel mailing list <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a> ------------------------------ End of libqmi-devel Digest, Vol 102, Issue 8 ******************************************** </blockquote></div>