Bug 829993 - ti_usb_3410_5052 USB serial device slow to appear
ti_usb_3410_5052 USB serial device slow to appear
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 19:13 EDT by Darren Hart
Modified: 2012-09-12 12:32 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-12 12:32:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Darren Hart 2012-06-07 19:13:04 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.

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

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):
3.4.0-1.fc17.x86_64

How reproducible:
100%

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
  
Actual results:
$ time while true; do if [ -e /dev/ttyUSB0 ]; then break; fi; done
real	0m31.922s
user	0m26.976s
sys	0m4.113s


Expected results:
It should only take 3 seconds or so for the device to appear.

Additional info:
Dmesg reports:
[ 4184.551065] usb 1-1.5.4.3: new full-speed USB device number 19 using ehci_hcd
[ 4184.680236] usb 1-1.5.4.3: New USB device found, idVendor=0451, idProduct=5053
[ 4184.680238] usb 1-1.5.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4184.680240] usb 1-1.5.4.3: Product: Fish River Island
[ 4184.680242] usb 1-1.5.4.3: Manufacturer: Kontron Penang
[ 4184.680243] usb 1-1.5.4.3: SerialNumber: LF07001112000457
[ 4184.681524] ti_usb_3410_5052 1-1.5.4.3:1.0: TI USB 3410 1 port adapter converter detected
[ 4184.681535] ti_usb_3410_5052: probe of 1-1.5.4.3:1.0 failed with error -5
[ 4184.682633] ti_usb_3410_5052 1-1.5.4.3:2.0: TI USB 3410 1 port adapter converter detected
[ 4184.682701] usb 1-1.5.4.3: 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.
Comment 1 Josh Boyer 2012-07-05 14:40:09 EDT
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?

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