Red Hat Bugzilla – Bug 829993
ti_usb_3410_5052 USB serial device slow to appear
Last modified: 2012-09-12 12:32:31 EDT
Description of problem:
The serial console on my Atom development board is implemented using a tu_usb_3410_5052 uart to serial converter on an internal daughter card.
When the device is powered off, the serial device is removed, when it is powered on, it reappears.
In Fedora 16 with the 3.3.7 kernel, the device would appear in about 3 seconds, in plenty of time to work with the BIOS and the boot loader. In Fedora 17, with the 3.4.0-1.fc17.x86_64 kernel, it can take over 30 seconds to appear, and the device is well into the kernel boot process by then.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Connect the device to the Fedora 17 (64) host via a micro USB cable
2. Load the module:
modprobe ti_usb_3410_5052 vendor_3410=0x0451 product_3410=0x5053
3. Wait for the device to appear:
time while true; do if [ -e /dev/ttyUSB0 ]; then break; fi; done
$ time while true; do if [ -e /dev/ttyUSB0 ]; then break; fi; done
It should only take 3 seconds or so for the device to appear.
[ 4184.551065] usb 1-184.108.40.206: new full-speed USB device number 19 using ehci_hcd
[ 4184.680236] usb 1-220.127.116.11: New USB device found, idVendor=0451, idProduct=5053
[ 4184.680238] usb 1-18.104.22.168: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4184.680240] usb 1-22.214.171.124: Product: Fish River Island
[ 4184.680242] usb 1-126.96.36.199: Manufacturer: Kontron Penang
[ 4184.680243] usb 1-188.8.131.52: SerialNumber: LF07001112000457
[ 4184.681524] ti_usb_3410_5052 1-184.108.40.206:1.0: TI USB 3410 1 port adapter converter detected
[ 4184.681535] ti_usb_3410_5052: probe of 1-220.127.116.11:1.0 failed with error -5
[ 4184.682633] ti_usb_3410_5052 1-18.104.22.168:2.0: TI USB 3410 1 port adapter converter detected
[ 4184.682701] usb 1-22.214.171.124: TI USB 3410 1 port adapter converter now attached to ttyUSB0
I was surprised to see that the kernel time stamp between the last two lines does not match the time it actually takes to create the device.
On one test, the minicom command hung trying to open the device (the minicom UI never appeared), the console stopped accepting input, and new consoles would not start. This lasted for several minutes.
Udev is responsible for creating device nodes. If you run 'udevadm monitor' do you see the kernel events for the device coming in at times corresponding to what the kernel prints?