On Fri, Dec 16, 2011 at 10:00:01PM +0000, Tim Coote wrote: > 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. What are the log messages here? > 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. No, that doesn't really work given the structure of how USB works, sorry. > 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 So the device went away, that's normal, and should be fine. Where are the error messages in the log? thanks, greg k-h -- 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