linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: Paul Gildea <paul.gildea@gmail.com>
Cc: "davem\@davemloft.net" <davem@davemloft.net>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: usb: qmi_wwan: Fix for packets being rejected in the ring buffer used by the xHCI controller.
Date: Sun, 08 Mar 2020 16:26:21 +0100	[thread overview]
Message-ID: <87wo7una02.fsf@miraculix.mork.no> (raw)
In-Reply-To: <CA+4pmEueEiz0Act8X6t4y3+4LOaOh_-ZfzScH0CbOKT99x91NA@mail.gmail.com> (Paul Gildea's message of "Wed, 4 Mar 2020 14:20:28 +0000")

Paul Gildea <paul.gildea@gmail.com> writes:

> When MTU of modem is set to less than 1500 and a packet larger than MTU
> arrives in Linux from a modem, it is discarded with -EOVERFLOW error
> (Babble 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. Following the babble error there were 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, rendering the modem
> unusable. There is 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.
>
> Signed-off-by: Paul Gildea <Paul.Gildea@gmail.com>
> ---
> drivers/net/usb/qmi_wwan.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 5754bb6..545c772 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -815,6 +815,13 @@ static int qmi_wwan_bind(struct usbnet *dev, struct
> usb_interface *intf)
>     }
>     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.
> +    */
> +   dev->rx_urb_size = ETH_DATA_LEN + 4;
>  err:
>     return status;
>  }
> --
> 1.9.1


This is fine as a first step towards saner buffer handling in qmi_wwan.
If real world devices use asymmetric MTUs, then we should just deal with
that.

So I was going to add my ack.  But the patch does not apply:


 bjorn@miraculix:/usr/local/src/git/linux$ git am /tmp/l
 Applying: net: usb: qmi_wwan: Fix for packets being rejected in the ring buffer used by the xHCI controller.
 error: corrupt patch at line 10

and checkpatch says why:

 bjorn@miraculix:/usr/local/src/git/linux$ scripts/checkpatch.pl /tmp/l
 ERROR: patch seems to be corrupt (line wrapped?)
 #34: FILE: drivers/net/usb/qmi_wwan.c:814:
 usb_interface *intf)


Could you fix up and resend? You might have to use a different email
client.  See
https://www.kernel.org/doc/html/latest/process/email-clients.html#email-clients


Bjørn

       reply	other threads:[~2020-03-08 15:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+4pmEueEiz0Act8X6t4y3+4LOaOh_-ZfzScH0CbOKT99x91NA@mail.gmail.com>
2020-03-08 15:26 ` Bjørn Mork [this message]
2020-03-08 19:07   ` [PATCH] net: usb: qmi_wwan: Fix for packets being rejected in the ring buffer used by the xHCI controller Daniele Palmas
2020-09-07  7:25     ` Kristian Evensen
2020-09-07  7:45       ` Bjørn Mork
2020-09-07  8:35         ` Daniele Palmas
2020-09-07  8:49           ` Kristian Evensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wo7una02.fsf@miraculix.mork.no \
    --to=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul.gildea@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).