libqmi-devel Digest, Vol 102, Issue 8

Wed May 27 13:34:12 UTC 2020

HI Amol, afraid I don't know as I don't use that.

--
Paul

On Wed, 27 May 2020 at 04:06, Amol Lad <Amol.Lad at 4rf.com> wrote:

> 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>
> 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
> ********************************************
>
> ------------------------------
> 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/3053c8d3/attachment.htm>