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.
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.
Created attachment 102006 [details] output from /sbin/lsmod
Created attachment 102007 [details] output from /sbin/lsmod Shows usbserial, ohci_hcd, cdc_acm kernel modules are loaded.
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.
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.)
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.
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.
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.)
fixed with current updates ?
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."
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.
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.
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.
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.
[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.
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.
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.
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?
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?
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.])