Bug 127951 - /dev/input/ttyACM0: No such device or address
/dev/input/ttyACM0: No such device or address
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-15 12:51 EDT by John Reiser
Modified: 2015-01-04 17:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-29 17:53:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from /sbin/lsmod (1.46 KB, text/plain)
2004-07-17 15:27 EDT, John Reiser
no flags Details
output from /sbin/lsmod (1.46 KB, text/plain)
2004-07-17 15:28 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2004-07-15 12:51:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625

Description of problem:
/dev/input/ttyACM0 gives no response; there is a USB modem plugged in
and turned on.  [Permissions have been changed to 0666 to allow
access.]  /proc/usb/devices doesn't exist, either [kudzu ?]



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

How reproducible:
Always

Steps to Reproduce:
1. Plug in and turn on USB modem.
2. chmod a+rw /dev/input/ttyACM0
3. < /dev/input/ttyACM0  ## try to read

    

Actual Results:  bash: /dev/input/ttyACM0: No such device or address


Expected Results:  No complaint.


Additional info: /sbin/lsmod shows usbserial is loaded.  Mouse is USB
and works.  /proc/interrupts shows two ohci_hcd sources.  /sbin/lsmod
shows _no_ ohci drivers.
Comment 1 John Reiser 2004-07-17 15:26:25 EDT
After updating to kernel-2.6.7-1.492, then kudzu recognizes the modem
and configures it, and it appears in /proc/bus/usb/devices.  After
symlinking /dev/modem -> input/ttyACM0 to get around the problem that
subsystem locking cannot handle a three-tier pathname
[/dev/input/ttyACM0], and changing permissions to rw-rw-rw- on
/dev/input/ttyACM0, and setting /dev/modem to be the serial port in
minicom, then minicom fails with "minicom: cannot open /dev/modem:
Invalid argument".  An "strace -f minicom" shows that one problem is:
-----
open("/dev/modem", O_RDWR|O_NONBLOCK)   = -1 EINVAL (Invalid argument)
-----
Kernel modules ohci_hcd, usbserial, and cdc_acm are loaded.  I will
attach the complete output from lsmod.


Comment 2 John Reiser 2004-07-17 15:27:38 EDT
Created attachment 102006 [details]
output from /sbin/lsmod
Comment 3 John Reiser 2004-07-17 15:28:29 EDT
Created attachment 102007 [details]
output from /sbin/lsmod

Shows usbserial, ohci_hcd, cdc_acm kernel modules are loaded.
Comment 4 John Reiser 2004-07-18 11:19:29 EDT
Trying usb hotplug machinery (kernel 2.6.7-1.492): Reboot with modem
turned off.  Kudzu notices, user OKs a Remove configuration.  Turn
modem on.  log shows:
----- /var/log/messages
Jul 18 07:41:44 fc3test1 kernel: usb 2-1: new full speed USB device
using address 2
Jul 18 07:41:44 fc3test1 kernel: usb 2-1: configuration #2 chosen from
2 choices
Jul 18 07:41:46 fc3test1 usb.agent[2662]: Keeping default
configuration with /sys//devices/pci0000:00/0000:00:01.3/usb2/2-1
Jul 18 07:41:49 fc3test1 su(pam_unix)[2739]: session opened for user
root by jreiser(uid=500)
Jul 18 07:49:37 fc3test1 kernel: drivers/usb/class/cdc-acm.c: Ignoring
extra header
Jul 18 07:49:37 fc3test1 kernel: usbcore: registered new driver cdc_acm
Jul 18 07:49:37 fc3test1 kernel: drivers/usb/class/cdc-acm.c:
v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters
-----

Using /proc/bus/usb/devices, locate modem as bus 2, device 2.  Set
symlink /dev/modem -> /proc/bus/usb/002/002 and chmod to 0666. 
Minicom thinks the device is there, but there is no communication with
the modem (no echo on minicom xterm of intialization string, and no
flashing lights on modem).  Strace shows
----- strace -f minicom
open("/dev/modem", O_RDWR|O_NONBLOCK)   = 3
fcntl64(3, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(3, F_SETFL, O_RDWR)             = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xfef0205c) = -1 ENOTTY
(Inappropriate ioctl for device)
ioctl(3, TIOCMGET, [0])                 = -1 ENOTTY (Inappropriate
ioctl for device)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xfef01fdc) = -1 ENOTTY
(Inappropriate ioctl for device)
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon
-echo ...}) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(3, TIOCMGET, [0])                 = -1 ENOTTY (Inappropriate
ioctl for device)
ioctl(3, TIOCMSET, [TIOCM_RTS])         = -1 ENOTTY (Inappropriate
ioctl for device)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xfef01f7c) = -1 ENOTTY
(Inappropriate ioctl for device)
ioctl(3, SNDCTL_TMR_START or TCSETS, {B4800 -opost -isig -icanon echo
...}) = -1 ENOTTY (Inappropriate ioctl for device)
    [snip]
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xfef0207c) = -1 ENOTTY
(Inappropriate ioctl for device)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xfef0207c) = -1 ENOTTY
(Inappropriate ioctl for device)
ioctl(3, SNDCTL_TMR_START or TCSETS, {B0 opost -isig -icanon -echo
...}) = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})               = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B600 opost -isig -icanon -echo
...}) = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})               = 0
write(3, "\r", 1)                       = -1 EINVAL (Invalid argument)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})               = 0
write(3, "A", 1)                        = -1 EINVAL (Invalid argument)
write(3, "T", 1)                        = -1 EINVAL (Invalid argument)
write(3, " ", 1)                        = -1 EINVAL (Invalid argument)
write(3, "S", 1)                        = -1 EINVAL (Invalid argument)
write(3, "7", 1)                        = -1 EINVAL (Invalid argument)
write(3, "=", 1)                        = -1 EINVAL (Invalid argument)
-----
so somehow tty driver is not connected to cdc_acm.

Comment 5 John Reiser 2004-08-02 00:25:55 EDT
The device works under SuSE Personal Linux 9.10 (same hardware,
multi-booting.)  The message in /var/log/messages is
-----
Aug  1 21:07:26 linux kernel: cdc_acm 2-1:2.0: ttyACM0: USB ACM
device<6>drivers/usb/core/usb.c: registered new driver cdc_acm
Aug  1 21:07:26 linux kernel: drivers/usb/class/cdc-acm.c: v0.23:USB
Abstract Control Model driver for USB modems and ISDN adapters
-----
while on FC3t1 the message is
-----
Aug  1 21:18:27 fc3test1 kernel: usbcore: registered new driver cdc_acm
Aug  1 21:18:27 fc3test1 kernel: drivers/usb/class/cdc-acm.c:
v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters
-----
The SuSE system has usbfs mounted on /proc/bus/usb type usbfs (rw).
The FC3t1       has usbdevfs      on /proc/bus/usb type usbdevfs (rw).
Both systems had kernel module cdc_acm loaded.  SuSE also had module
usbcore loaded; it looks like FC3t1 has usbcore builtin.  The SuSE
device name is /dev/ttyACM0 (no .../input/...) but it's still "c 166
0", and permissions were set to 0666 in both cases.

The command "strace cat /dev/input/ttyACM0" on FC3t1 shows
-----
open("/dev/input/ttyACM0", O_RDONLY|O_LARGEFILE) = -1 EINVAL (Invalid
argument)
-----
while the analogous commandline on the SuSE system succeeds (including
the open() with O_LARGEFILE.)


Comment 6 John Reiser 2004-08-05 17:40:35 EDT
Please tell me where to start finding out why
open("/dev/input/ttyACM0", O_RDONLY | O_LARGEFILE) gives EINVAL. 
(Kernel module cdc_acm has been loaded, else the error is ENXIO
instead; filesystem permissions allow the operation.)  I can
re-compile kernels and/or modules, run in debug mode, etc., but I do
not know how to track down where the open() gives EINVAL.
Comment 7 W. Michael Petullo 2004-08-28 12:42:31 EDT
I am having the same problem.  My modem is a pretty generic USB model
from Best Data.  The modem seems to be detected by the kernel and
shows up in /proc/bus/usb/devices.  The modem worked fine until
recently.  The last time my logs show a successful ppp connection was
August 1st (I generally connect using a DSL modem unless bug
squashing).  I would have been using an up to date rawhide as of
August 1st.
Comment 9 John Reiser 2004-08-31 10:57:45 EDT
Today /usr/bin/minicom works, if setup with /dev/modem ->
input/ttyACM0 and permissions adjusted.  This is with
   kernel-2.6.8-1.533
   initscripts-7.73-1
   udev-030-10
   kudzu-1.1.82-1
which I believe is up2date.

$ /sbin/lsmod | egrep 'acm|usb|ser'
usbserial              22057  0
cdc_acm                10081  0
$  # modules were loaded automatically (not by hand)

/proc/bus/usb/ is empty, and "cat /proc/bus/usb/devices" gives ENOENT.
The only USB-related entries in /etc/sysconfig/hwconf are for the two
ohci-hcd controllers.  (USB mouse and USB modem do not appear in hwconf.)
Comment 10 Dave Jones 2004-12-07 01:50:38 EST
fixed with current updates ?
Comment 11 W. Michael Petullo 2004-12-07 13:25:34 EST
My issue still remains with kernel-2.6.9-1.1006_FC4.  See comment #7.
 Plugging the modem in causes the cdc_acm kernel module to be loaded.
 However, the module does not seem to claim the device.  The modem's
entry in /proc/bus/usb/devices contains:

I: ... Driver=(none)

Also, the device is not created by udev in /dev/input/.

If I create /dev/input/ttyACM0 by hand then "echo 0 >
/dev/input/ttyACM0" says "bash: ttyACM0: Invalid argument."
Comment 12 John Reiser 2004-12-07 13:34:22 EST
It works for me today on FC3 using
  kernel-2.6.9-1.681_FC3
  initscripts-7.93.5-1
  udev-039-10.FC3.5
  kudzu-1.1.95-1

In detail: USB modem was plugged in and turned on before power-on
boot.  Kudzu noticed the device during boot, I chose "Configure", and
kudzu made an entry for the modem in /etc/sysconfig/hwconf. 
/dev/ttyACM0 [note no ".../input/..."] was made as a character device
with major=166, minor=0.  I set the permissions manually to rw-rw-rw-.
 minicom talked to the device [although "minicom -s" needed manual
poking to get over initial display glitches with ncurses.] 
/proc/bus/usb/devices contains a description of the modem, the mouse,
and the two ohci controllers.
 
Comment 13 W. Michael Petullo 2004-12-07 17:10:54 EST
John, could you provide the contents of /proc/bus/usb/devices?  I am
curious if the cdc_acm driver claims your modem.  My does not seem to
be claimed by the cdc_acm driver: "I: ... Driver=(none)."  Also, what
model of modem are you using?  Mine is a Best Data 56USBP.
Comment 14 John Reiser 2004-12-07 17:48:20 EST
Michael, here is the modem portion of /proc/bus/usb/devices:
-----
T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  2
P:  Vendor=0803 ProdID=9700 Rev= 1.00
S:  Manufacturer=Zoom Telephonics, Inc.
S:  Product=Zoom V90 USB Faxmodem
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=400mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=02(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=84(I) Atr=03(Int.) MxPS=  63 Ivl=2ms
C:* #Ifs= 2 Cfg#= 2 Atr=a0 MxPwr=400mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=84(I) Atr=03(Int.) MxPS=  32 Ivl=128ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
-----
where I see three "Driver=" sections: two with cdc_acm, and one with
an empty string.

From /etc/sysconfig/hwconf, the modem is:
-----
class: OTHER
bus: USB
detached: 0
driver: unknown
desc: "Zoom Telephonics, Inc. 2986L FaxModem"
usbclass: 0
usbsubclass: 2
usbprotocol: 1
usbbus: 1
usblevel: 1
usbport: 2
usbdev: 3
vendorId: 0803
deviceId: 9700
usbmfr: Zoom Telephonics, Inc.
usbprod: Zoom V90 USB Faxmodem
-
class: OTHER
bus: USB
detached: 0
driver: unknown
desc: "Zoom Telephonics, Inc. 2986L FaxModem"
usbclass: 0
usbsubclass: 0
usbprotocol: 0
usbbus: 1
usblevel: 1
usbport: 2
usbdev: 3
vendorId: 0803
deviceId: 9700
usbmfr: Zoom Telephonics, Inc.
usbprod: Zoom V90 USB Faxmodem
-----
where there are two sections with different subclass and protocol.
I guess your device might not be matched by one of the descriptions in
the /etc/hotplug/usb.* files.
Comment 15 W. Michael Petullo 2004-12-07 18:01:32 EST
So, is it possible that a change between August's kernel and 2.6.9
drops support for the Best Data modem?

Vendor=0572
ProdID=1280

I could not find where in the kernel sources the vendors and product
ID's were listed for the cdc_acm driver.  The hotplug system seems to
recognize the modem because the cdc_acm driver is automatically
loaded.  But the driver does not pick up on the existence of the modem.
Comment 16 John Reiser 2004-12-08 10:16:42 EST
[I'm not sure that all of this reasoning is correct, but anyway ...] 
In /etc/hotplug/usb.distmap, I believe the relevant line is
-----
acm                  0x0070 0x0000   0x0000    0x0000       0x0000   
   0x02         0x00            0x00            0x00            0x00 
          0x00            0x00000000
-----
where the "key" for column headings is given as line 1:
-----
# usb module         match_flags idVendor idProduct bcdDevice_lo
bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol
bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
-----
So 0x0070 means match on bDeviceClass, bDeviceSubClass, and
bDeviceProtocol.  The bits are inspected from low to high, so 0x0070
means "skip 4 colummns (idVendor, idProduct, bcdDevice_lo,
bcdDevice_hi), match on the next 3 columns (bDeviceClass=2,
bDeviceSubClass=0, bDeviceProtocol=0), and skip all the rest.  The
Device info should correlate with the listing in
/etc/sysconfig/hwconf.  There, one of the listings for my modem has
-----
usbclass: 0
usbsubclass: 2
usbprotocol: 1
-----
and the other listing for my modem has
-----
usbclass: 0
usbsubclass: 0
usbprotocol: 0
-----

But now I'm stuck, becuase (0,2,1) and (0,0,0) from hwconf seem to
mismatch (2,0,0) from usb.distmap.  Then there is also the "cdc_acm"
vs. "acm" mismatch.

Comment 17 W. Michael Petullo 2004-12-08 10:29:01 EST
I'm not too concerned about the hotplug side of things.  The cdc_acm
module is being loaded automatically, so I think that hotplug is
working fine.  I don't think I am interested in kudzu either (is kudzu
relevant for a USB modem?).  The thing that concerns me is that the
cdc_acm driver does not seem to claim control of my modem.
Comment 18 Dave Jones 2005-04-16 01:54:09 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.
Comment 19 W. Michael Petullo 2005-04-16 13:15:23 EDT
All of the comments that I have made still apply to the current Raw Hide kernel
(kernel-2.6.11-1.1240_FC4), etc.  I do not have permission to reopen this bug or
change its version to devel.  Could someone else do this for me?
Comment 20 W. Michael Petullo 2005-05-28 22:10:20 EDT
This seems fixed in kernel-2.6.11-1.1340_FC4.  The cdc_acm driver now claims my
modem and udev creates /dev/ttyACM0.  John, can you verify this and close this bug?
Comment 21 John Reiser 2005-05-29 17:53:05 EDT
Today using
  kernel-2.6.11-1.1363_FC4   # FC4 test 3
  initscripts-8.11.1-1
  kudzu-1.1.116.2-2
  udev-058-1
I see:
-----
$ ls -l /dev/ttyACM0
crw-rw----  1 root root 166, 0 May 29 14:30 /dev/ttyACM0
$ /sbin/lsmod | egrep 'acm|usb|ser'
cdc_acm                13409  0
$ cat /proc/bus/usb/devices  # edited to list only the modem
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  2
P:  Vendor=0803 ProdID=9700 Rev= 1.00
S:  Manufacturer=Zoom Telephonics, Inc.
S:  Product=Zoom V90 USB Faxmodem
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=400mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=02(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=84(I) Atr=03(Int.) MxPS=  63 Ivl=2ms
C:* #Ifs= 2 Cfg#= 2 Atr=a0 MxPwr=400mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=84(I) Atr=03(Int.) MxPS=  32 Ivl=128ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

# cat /proc/tty/drivers
/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
rfcomm               /dev/rfcomm   216 0-255 serial
acm                  /dev/ttyACM   166 0-31 serial
serial               /dev/ttyS       4 64-139 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
unknown              /dev/tty        4 1-63 console
# 
-----
and /etc/sysconfig/hwconf lists no modem, and kudzu did not present any
configuration dialogs at boot, even though modem was plugged in and turned on
before power-on boot of CPU.  /dev/ttyACM0 did not exist before; presumably udev
 created it.  The modem has been claimed by acm, and it appeas in /proc/tty/drivers.

So, it looks like this bug has been fixed.  In particular, the original "Steps
to reproduce", changed to use /dev/ttyACM0 instead of /dev/input/ttyACM0:
  # chmod a+rw /dev/ttyACM0
  # < /dev/ttyACM0  ## try to read
now work correctly: no complain from shell.

(Trying to configure a new modem still fails because "no modem found on your
system", yet succeeds when the symlink /dev/modem -> /dev/ttyACM0 is created by
hand.  But this belongs to system-config-* and not to the kernel.  Also, once
/dev/modem exists and dialup configuration info has been entered, then
activating the device proceeds to dial.  [The dialup account is not active, so I
cannot report further right now.])




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