Bug 727610 - acm/ttyACM0/cdc_acm does not deliver data
Summary: acm/ttyACM0/cdc_acm does not deliver data
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-02 15:20 UTC by Arne Woerner
Modified: 2011-11-22 06:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-11-22 06:37:00 UTC

Attachments (Terms of Use)

Description Arne Woerner 2011-08-02 15:20:11 UTC
Description of problem:
my self-tinkered chorded keyboard does not deliver key press/release messages with 2.6.40-4.fc15, although it works fine with
on another box (atom N270 (i686)) i have the same problem with another ACM device (self-tinkered) and 2 USB DVB-T TV sticks (vendor: Hauppauge).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. reboot
2. start a program that reads from /dev/ttyACM0
Actual results:
open works as before, but nothing is read.

Expected results:
there should be some incoming data.

Additional info:
i found it remarkable, that it fails on 2 boxes, 2 architectures and 2 USB devices.

Comment 1 Arne Woerner 2011-08-18 12:29:37 UTC
with i still have those problems...

on i686 it crashes after a few minutes (no ethernet access... it is head-less, so that i cant c any special error messages...)...


Comment 2 Arne Woerner 2011-09-07 09:18:01 UTC still doesnt like my USB device... -arne

Comment 3 Arne Woerner 2011-10-06 10:14:54 UTC still doesnt treat my ttyACM devices as before...
i had a closer look at it, and now it seems, that it holds back a byte in some buffer, so that a read fails... when a write a further byte, the following read delivers the byte that i expected before...

i think that is a bug in the ACM or USB buffer handling, because: there is no guarantee that there is an infinitely long data stream coming from a serial port...


Comment 4 Josh Boyer 2011-10-06 12:56:01 UTC
You should probably email upstream about this.  We don't have the hardware to recreate issues and thus far you're the only person reporting a problem.

Comment 5 Arne Woerner 2011-10-12 22:44:03 UTC
at linux-kernel mailing list they suggested that the fedora-patches might have caused the trouble...
i could falsify that theory (i used the fc15 kernel SRPM for and hacked the SPECS file so that it would be a vanilla kernel (kernel-vanilla-

furthermore i gave them some usbmon traces some days ago, but nobody replied yet (maybe they r angry, because i forgot the subject line once...)...

a communication that works with both kernels (it is just about 1msec long):

a communication that works with the kernel but not the 2.6.40 kernel (it has a 50msec pause in the middle, where no USB stuff can be done... my self-tinkered-usb-device talks to some other device in that time, which takes its full concentration... but it is still a bug, that 1 byte hangs in some buffer, i think...):


Comment 6 Arne Woerner 2011-11-22 06:37:00 UTC
yesterday i made my self tinkered USB device more USB compliant...
since then the current 2.6.41 kernel works fine...
the TV sticks work fine again, 2... :-)

Note You need to log in before you can comment on or make changes to this bug.