linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Bug: cdc_acm blocking write after many small writes
@ 2019-04-05 15:09 Linus K.
  2019-04-08  7:32 ` Oliver Neukum
  0 siblings, 1 reply; 2+ messages in thread
From: Linus K. @ 2019-04-05 15:09 UTC (permalink / raw)
  To: linux-usb

Hi,
I recently submitted this bug to https://bugzilla.kernel.org/ and was 
redirected here.

Using a Atmel Evo Kit (which is recognized as /dev/ttyACM0).

When writing many small chunks of data to it, it'll block write forever 
(at least many minutes using select call).
Writing anyway causes errno 11: Resource temporarily not available.

This seems to be a race condition or buffer overflow since adding a 
small sleep of 1ms between writes (of 1 byte or similar small) defers 
the point of getting stuck.
Without sleep I can push about 240 bytes and with 1ms sleep I get a lot 
more (e.g. about 105680).

Also writing bigger chunks doesn't seem to produce the problem.
I can't use that as a solution hover since I need to keep the delay as 
small as possible.
Meaning small packets (often 1 to 3 bytes) and no caching.

The used serial devices has a set baud of 115200 symbols/sec (no parity, 
8 bytes, 1 stopbit).

I should also not that I didn't run into the bug writing as much data as 
possible.
I ran 2 writes of 1 byte every 16.667ms (60 Hz) which caused the program 
to get stuck after about 5-20 seconds.
The program is implemented using python, has 2 extra threads but only 
uses the serial connection (reading and writing) in the main thread.

I also tried different usb ports (separate root hubs).

This bug doesn't exists on my RaspberryPi this bug didn't exist on 
kernel 4.14.98-v7+ and probably before.
The raspberrypi only had the occasional pause when exceeding writing 
more than the device could handle and resumes asap (as expected).

The same problem also doesn't exists when using a FTDI as well as a 
CP2102 on my PC.

(I also disabled the ModemManager service which tried to communicate 
with the device using Hayes (AT) commands.)

There is no kernel log regarding the bug. Tested using USB 2 as as well 
as USB 3.
Kernel log when plugging in affected device:
[ 6184.123072] usb 2-10.2: New USB device found, idVendor=03eb, 
idProduct=2404, bcdDevice= 1.00
[ 6184.123076] usb 2-10.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[ 6184.123078] usb 2-10.2: Product: CDC
[ 6184.123080] usb 2-10.2: Manufacturer: ATMEL ASF
[ 6184.131485] cdc_acm 2-10.2:1.0: ttyACM0: USB ACM device
---


Greetings,
Linus Kaschulla (currently studing, using linux for many years and 
getting my feed wet with c programming with linux)


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Bug: cdc_acm blocking write after many small writes
  2019-04-05 15:09 Bug: cdc_acm blocking write after many small writes Linus K.
@ 2019-04-08  7:32 ` Oliver Neukum
  0 siblings, 0 replies; 2+ messages in thread
From: Oliver Neukum @ 2019-04-08  7:32 UTC (permalink / raw)
  To: Linus K., linux-usb

On Fr, 2019-04-05 at 17:09 +0200,  Linus K.  wrote:
> Hi,
> I recently submitted this bug to https://bugzilla.kernel.org/ and was 
> redirected here.

Hi,

does your kernel have

commit df3aa13c7bbb307e172c37f193f9a7aa058d4739
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Sep 5 17:56:46 2018 +0200


    Revert "cdc-acm: implement put_char() and flush_chars()"

and

commit 93e1c8a638308980309e009cc40b5a57ef87caf1
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Fri Mar 22 16:53:02 2019 +0100

    usb: cdc-acm: fix race during wakeup blocking TX traffic

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-04-08  7:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-05 15:09 Bug: cdc_acm blocking write after many small writes Linus K.
2019-04-08  7:32 ` Oliver Neukum

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).