Bug 829993

Summary: ti_usb_3410_5052 USB serial device slow to appear
Product: [Fedora] Fedora Reporter: Darren Hart <darren>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: ---

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?