libqmi-devel Digest, Vol 102, Issue 8

Fri Jun 12 07:41:27 UTC 2020

Hi Paul,

So I have done some tests. I have enabled dynamic debugging and enable
debugging for the following drivers:

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

I’m not seeing the same debug messages like the ones below as you are:

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

I have double checked and figured out that the modem is using USB 2.0, so
not the same issue as you were having.

I am still seeing the following messages and modem still disconnects after
a few messages:

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

*Geert*

On Wed, 27 May 2020 at 18:27, Geert Lens <g.lens at livetech-systems.com>
wrote:

> Hi Paul,
>
> Accidentally sent the email without finishing it.
> Thank you for your response. I'm going to check if I can see the same
> errors and will try out your fix to see if it helps.
> Will keep you posted.
>
> *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
>>
> --
*Geert Lens*
Kabelweg 57, 1014 BA, Amsterdam
Tel.: +31(0)20 2103141
www.livetech-systems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200612/421badcc/attachment-0001.htm>