<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Paul,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Accidentally sent the email without finishing it. </div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small">Will keep you posted.</div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><div><b>Geert</b></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 May 2020 at 15:34, Paul Gildea <<a href="mailto:gildeap@tcd.ie">gildeap@tcd.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">HI Amol, afraid I don't know as I don't use that.<div><br></div><div>--</div><div>Paul</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 May 2020 at 04:06, Amol Lad <<a href="mailto:Amol.Lad@4rf.com" target="_blank">Amol.Lad@4rf.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-NZ">
<div>
<p class="MsoNormal"><span>Hi Paul,<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Does same problem occur with MBIM as well?<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Amol<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> libqmi-devel <<a href="mailto:libqmi-devel-bounces@lists.freedesktop.org" target="_blank">libqmi-devel-bounces@lists.freedesktop.org</a>>
<b>On Behalf Of </b>Paul Gildea<br>
<b>Sent:</b> Tuesday, 26 May 2020 6:43 PM<br>
<b>To:</b> libqmi (development) <<a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a>><br>
<b>Subject:</b> Re: libqmi-devel Digest, Vol 102, Issue 8<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi Geert,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I am seeing this -71 EPROTO error on two occasions. The one I am currently seeing is happening with Telit LN960A18's. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We pass traffic over the modem with iperf3 and it resets after a time period with those errors, usually within 30 minutes.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">kernel debug and am seeing a "do warm reset" debug message from the driver (hub.c) and have been trying to track down why.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The second was covered in detail in another thread on here called "MTU issues", here was the finding:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Enabled traces for usbnet.c and xhci-ring.c file in debugfs as follows:<br>
<span><span style="font-family:"Courier New";color:rgb(80,0,80)">mount -t debugfs none /sys/kernel/debug</span></span><span style="font-family:"Courier New";color:rgb(80,0,80)"><br>
<span>echo -n 'file usbnet.c +p' > /sys/kernel/debug/dynamic_debug/control</span><br>
</span><span style="font-family:"Courier New"">echo -n 'file xhci-ring.c +p' > /sys/kernel/debug/dynamic_debug/control</span><br>
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:<br>
<span style="font-family:"Courier New"">xhci_hcd 0000:00:14.0: Babble error for slot 10 ep 12 on endpoint<br>
xhci_hcd 0000:00:14.0: Giveback URB ffff8802193be540, len = 1024, expected = 1430, status = -75<br>
xhci_hcd 0000:00:14.0: Transfer error for slot 10 ep 12 on endpoint<br>
</span>/repeated<br>
Error -75 is EOVERFLOW, which makes sense as per<i> include/uapi/asm-generic/errno.h</i><br>
<span style="font-family:"Courier New"">#define EOVERFLOW 75 /* Value too large for defined data type */</span><br>
<b>"Babble error"</b>: When a packet larger than <span>MTU</span> arrives in Linux from the modem and is discarded with -EOVERFLOW error.<br>
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 <span>MTU</span> (Max Transmit Size) and the received packets can be larger than those transmitted.<br>
<b>"Endless input error"</b>: 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).<br>
This is only seen on USB3.0. These continue to come ad infinitum until the modem is shutdown.<br>
There appears to be a bug in the core USB handling code in Linux that doesn't deal well with network <span>MTUs</span> smaller than 1500 bytes. By default the dev->hard_mtu (the "real" <span>MTU</span>) 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 <span>MTU</span> to 1430, and pinging with
size greater than 1406.<br>
Will submit the below patch that solves the issue, if that is acceptable?<br>
<span style="font-family:Arial,sans-serif"><br>
+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<br>
+--- linux-4.14.73/drivers/net/usb/qmi_wwan.c 2018-09-29 11:06:07.000000000 +0100<br>
++++ linux-4.14.73-rx_size_fix/drivers/net/usb/qmi_wwan.c 2020-01-31 18:05:07.709008785 +0000<br>
+@@ -740,6 +740,14 @@<br>
+ }<br>
+ dev->net->netdev_ops = &qmi_wwan_netdev_ops;<br>
+ dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;<br>
++<br>
++ /* LTE Networks don't always respect their own <span>MTU</span> on receive side;
<br>
++ * e.g. AT&T pushes 1430 <span>MTU</span> but still allows 1500 byte packets from
<br>
++ * far-end network. Make receive buffer large enough to accommodate<br>
++ * them, and add four bytes so <span>MTU</span> does not equal MRU on network<br>
++ * with 1500 <span>MTU</span> otherwise usbnet_change_mtu() will change both.<br>
++ * This is a sufficient max receive buffer as over 1500 <span>
MTU</span>, <br>
++ * USB driver issues are not seen.<br>
++ */<br>
++ dev->rx_urb_size = ETH_DATA_LEN + 4;<br>
+ err:<br>
+ return status;<br>
+ }</span><u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">--<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Paul <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Send libqmi-devel mailing list submissions to<br>
<a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" target="_blank">
https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:libqmi-devel-request@lists.freedesktop.org" target="_blank">
libqmi-devel-request@lists.freedesktop.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:libqmi-devel-owner@lists.freedesktop.org" target="_blank">
libqmi-devel-owner@lists.freedesktop.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of libqmi-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. USB errors with qmi-wwan (Geert Lens)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 25 May 2020 15:42:56 +0200<br>
From: Geert Lens <<a href="mailto:g.lens@livetech-systems.com" target="_blank">g.lens@livetech-systems.com</a>><br>
To: <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a><br>
Subject: USB errors with qmi-wwan<br>
Message-ID:<br>
<CAOCF0GO7xCyfRyTJmJnT=<a href="mailto:iZ9MoDCo6XL1Fa0YrOZz5GWm-%2Bd3g@mail.gmail.com" target="_blank">iZ9MoDCo6XL1Fa0YrOZz5GWm-+d3g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
We are using the QMI interface on the Quectel BG96 modem and everything<br>
works fine, but after a few hours the connection is suddenly disconnected<br>
and the qmi_proxy starts hogging CPU.<br>
<br>
During this time the USB interfaces of the modem are not responding and<br>
will only work again after the modem is physically turned off and on.<br>
<br>
Output from dmesg:<br>
<br>
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*<br>
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*<br>
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*<br>
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*<br>
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*<br>
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*<br>
*qmi_wwan 1-1:1.4: nonzero urb status received: -71*<br>
*qmi_wwan 1-1:1.4: wdm_int_callback - 0 bytes*<br>
<br>
I have read that the -71 (EPROTO) is mostly caused by hardware or firmware<br>
issues and that it can cause the kernel to disable the device, is<br>
this correct? Or could it be something else?<br>
<br>
Version used:<br>
- Linux kernel: v4.14.78<br>
- ModemManager: v1.12.10<br>
- libqmi: v1.24.10<br>
<br>
*Geert*<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200525/c827d211/attachment-0001.htm" target="_blank">https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200525/c827d211/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
libqmi-devel mailing list<br>
<a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of libqmi-devel Digest, Vol 102, Issue 8<br>
********************************************<u></u><u></u></p>
</blockquote>
</div>
</div>
<font color="#9a9a9a"><font style="font-size:8pt" face="Arial">
<hr style="font-size:8pt;font-family:Arial">
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).</font> </font>
</div>
</blockquote></div>
_______________________________________________<br>
libqmi-devel mailing list<br>
<a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank">libqmi-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a><br>
</blockquote></div>