Bug 727610 - acm/ttyACM0/cdc_acm does not deliver data
Summary: acm/ttyACM0/cdc_acm does not deliver data
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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 2.6.38.8-35.fc15.
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):
2.6.40-4.fc15

How reproducible:
always

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

-arne

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

Comment 3 Arne Woerner 2011-10-06 10:14:54 UTC
2.6.40.6-0.fc15.x86_64 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...

-arne

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 2.6.40.6-0 and hacked the SPECS file so that it would be a vanilla kernel (kernel-vanilla-2.6.40.6-0.local.fc15.x86_64.rpm))...

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):
http://www.wgboome.org/cmd:P-C,2.6.40.6-0.local.fc15.x86_64.usbmon

a communication that works with the 2.6.38.8 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...):
http://www.wgboome.org/cmd:Z-L-0,2.6.38.8-35.fc15.x86_64.usbmon
http://www.wgboome.org/cmd:Z-L-0,1st-try,2.6.40.6-0.fc15.x86_64.usbmon
http://www.wgboome.org/cmd:Z-L-0,2nd-try,2.6.40.6-0.fc15.x86_64.usbmon
http://www.wgboome.org/cmd:Z-L-0,2nd-try,2.6.40.6-0.local.fc15.x86_64.usbmon

-arne

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


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