On Fri, 16 Dec 2011, 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. It sounds like the device doesn't work properly when the Sun isn't up high enough for the solar panels to provide sufficient power. > 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. That's possible, but if it's true then it's the device's fault. The device has a fixed amount of time in which to carry out its initialization, as described in the USB spec. If it's not ready by the end of that time then it isn't compliant with the spec. > 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. As Greg mentioned, that won't work. USB devices never push out requests; there's no way for them to do it. > 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. You can simply unload uhci-hcd and then modprobe it back when the device is ready. > The device seems ok with Windows. That statement isn't very clear. You implied above that it also works with Linux -- but not when the Sun is too low. Does it work with Windows at that time (i.e., when it isn't getting enough power)? Alan Stern -- 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
