libqmi-devel Digest, Vol 102, Issue 8

Wed May 27 16:24:23 UTC 2020

Hi Paul,

Thank yo

*Geert*

On Wed, 27 May 2020 at 15:34, Paul Gildea <gildeap at tcd.ie> wrote:

> 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).
>>
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200527/04cea143/attachment-0001.htm>