From: Johan Hovold <johan@kernel.org>
To: Sven Brauch <mail@svenbrauch.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Oliver Neukum <oliver@neukum.org>,
Peter Hurley <peter@hurleysoftware.com>,
Toby Gray <toby.gray@realvnc.com>,
linux-usb@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] Fix data loss in cdc-acm
Date: Mon, 20 Jul 2015 19:25:46 +0200 [thread overview]
Message-ID: <20150720172546.GF20628@localhost> (raw)
In-Reply-To: <55AC1883.4050605@svenbrauch.de>
[ +CC: Alan, Oliver, Peter, Toby, linux-serial, linux-usb ]
On Sun, Jul 19, 2015 at 11:37:07PM +0200, Sven Brauch wrote:
> Since acm_process_read_urb does not check the return value
> of tty_insert_flip_string, it can happen that not all data
> is copied from the urb to the tty if the tty buffer
> is full and throttling does not set in quickly enough. This
> problem is very evident for devices with high data throughput;
> for a device with ~12 MB/s of data transfer, I get a few
> missing kB of data every few MB transferred randomly.
What kernel version are you using?
> To solve this problem, a check is introduced which verifies
> that indeed all data was copied from the urb to the tty buffer.
> If that is not the case, the urb is held in a queue instead
> of resubmitting it to the USB subsystem right away. When new
> data arrives or the tty is unthrottled, the queue is emptied
> again (as far as possible).
>
> Effectively, this change will force the transmitting USB device
> to wait until the tty buffer can accept new data again, instead
> of discarding the data in this case.
The idea of adding another layer of buffering in the cdc-acm driver has
been suggested in the past but was rejected (or at least questioned).
See for example this thread:
https://lkml.kernel.org/r/20110608164626.22bc893c@lxorguk.ukuu.org.uk
The tty buffers are quite large these days, but could possibly be bumped
further if needed to give the ldisc some more time to throttle the
device at very high speeds.
Johan
next parent reply other threads:[~2015-07-20 17:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55AC1883.4050605@svenbrauch.de>
2015-07-20 17:25 ` Johan Hovold [this message]
2015-07-20 18:07 ` [PATCH] Fix data loss in cdc-acm Sven Brauch
2015-07-21 9:18 ` Johan Hovold
2015-07-21 16:45 ` Peter Hurley
2015-07-22 8:40 ` Oliver Neukum
2015-07-22 14:30 ` Peter Hurley
2015-07-22 15:01 ` Oliver Neukum
[not found] ` <1437577303.5445.7.camel-IBi9RG/b67k@public.gmane.org>
2015-08-05 0:26 ` Peter Hurley
2015-07-21 13:43 ` Oliver Neukum
[not found] ` <1437486195.3823.13.camel-IBi9RG/b67k@public.gmane.org>
2015-07-21 21:43 ` Sven Brauch
2015-07-21 23:34 ` Peter Hurley
2015-07-22 0:47 ` Sven Brauch
2015-07-22 22:12 ` Peter Hurley
2015-07-22 22:53 ` Sven Brauch
2015-07-27 10:00 ` Peter Stuge
[not found] ` <55B01EDE.3050503-ITmcY+a7/CDoK6nBLMlh1Q@public.gmane.org>
2015-08-05 17:36 ` Peter Hurley
[not found] ` <55C249A3.6030809-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
2015-10-20 18:16 ` Peter Hurley
2015-10-21 10:12 ` Oliver Neukum
2015-10-21 12:09 ` Peter Hurley
2015-10-21 14:58 ` Peter Hurley
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=20150720172546.GF20628@localhost \
--to=johan@kernel.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mail@svenbrauch.de \
--cc=oliver@neukum.org \
--cc=peter@hurleysoftware.com \
--cc=toby.gray@realvnc.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).