coping with poor usb implementations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hullo

I'm running kernel 3.1.5 (fedora 16) on an old laptop as I'm trying to build a data logger for my solar panels. The data source has got the usual sort of nasty controller that one often finds: an xp driver for a device that used to be an RS232, but's now got a USB front end (based on the TI 3410 chip.)

The device turns off when the sun goes down, and when it comes up in the morning, it looks like the chatter from uhci_hcd is overwhelming the controller: I'm seeing the USB device come up and then reset about 250 times, with syslog full of this kind of entries at the bottom of this post. Once finally up, the controller does not behave properly and I have to perform a hard reset.

Reading around the web, I think that the issue is that uhci_hcd is trying to interrogate the device before it's completed it's initialisation. RS232 has no initialisation, but the USB subsystem seems to interrogate new devices to see what they are. I believe that this type of behaviour of controllers is not uncommon. I've already ripped out ModemManager and mtp probe, but it's still not working.  One of the approaches that's been adopted by the gpsd group, believe is to not probe the usb devices that are plugged, but to wait for them to push out a request. I'm not familiar with usb, but this doesn't sound terribly robust as I'm sure that there are devices that wait for the host to contact them.  Maybe it's possible to identify the behaviour of rapidly connecting/disconnecting devices and change the probing strategy.

In the short term, is there any way to get uhci_hcd to back off, either completely or until the device settles down. Simply putting a blacklist entry in /etc/modprobe.d/blacklist.conf does not seem to work.

The device seems ok with Windows.

Any help would be gratefully received.

Tim

Dec 16 08:47:01 pluto kernel: [74750.644053] usb 3-2: reset full speed USB device number 54 using uhci_hcd
Dec 16 08:47:02 pluto kernel: [74750.771372] usb 3-2: device firmware changed
Dec 16 08:47:02 pluto kernel: [74750.771407] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5
Dec 16 08:47:02 pluto kernel: [74750.771912] usb 3-2: USB disconnect, device number 54
Dec 16 08:47:02 pluto kernel: [74750.875053] usb 3-2: new full speed USB device number 55 using uhci_hcd
Dec 16 08:47:02 pluto kernel: [74751.077370] usb 3-2: New USB device found, idVendor=0451, idProduct=3410
Dec 16 08:47:02 pluto kernel: [74751.077379] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 16 08:47:02 pluto kernel: [74751.077386] usb 3-2: Product: TUSB3410 Boot Device
Dec 16 08:47:02 pluto kernel: [74751.077392] usb 3-2: Manufacturer: Texas Instruments
Dec 16 08:47:02 pluto kernel: [74751.077398] usb 3-2: SerialNumber: TUSB3410 
Dec 16 08:47:02 pluto kernel: [74751.080467] ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected
Dec 16 08:47:02 pluto kernel: [74751.080499] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5
Dec 16 08:47:02 pluto kernel: [74751.084511] ti_usb_3410_5052 3-2:2.0: TI USB 3410 1 port adapter converter detected
Dec 16 08:47:02 pluto kernel: [74751.084821] usb 3-2: TI USB 3410 1 port adapter converter now attached to ttyUSB0
Dec 16 08:47:05 pluto kernel: [74754.500080] usb 3-2: USB disconnect, device number 55
Dec 16 08:47:05 pluto kernel: [74754.500365] ti_usb_3410_5052_1 ttyUSB0: TI USB 3410 1 port adapter converter now disconnected from ttyUSB0
Dec 16 08:47:05 pluto kernel: [74754.500395] ti_usb_3410_5052 3-2:2.0: device disconnected--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux