Please use Reply-To-All so that your messages go to the mailing list as well as to me. On Sat, 17 Dec 2011, Tim Coote wrote: > On 17 Dec 2011, at 00:24, Alan Stern wrote: > > > 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. > That's my interpretation, too. > > > >> 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. > Indeed, it is 'the device's' fault. But, I believe, it's a common non-compliance. What makes you think so? Besides, if the problem is really caused by insufficient power from the solar panels, it can hardly be considered the device's fault. Does the device truly require an external power source (as opposed to running off the USB bus power)? Many USB-serial devices don't. > >> 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. > Is the implication here that it's not possible to put USB 'in front' > of legacy RS232 in a way that's compliant with USB? Not at all; it is indeed possible to do so. There are plenty of USB/RS232 converters available on the market. Linux has several dozen USB-serial drivers, many of which can control multiple types of devices. > That sounds like a design flaw in the USB spec. > > > >> 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. > That's what I thought. But it won't unload. I suspect that I simply > need to twiddle with the default fedora kernel parameters to make > uhci_hcd a module, rather than compiled in. Another possibility is to unbind uhci-hcd from the controller into which the device is plugged. You can do that without building uhci-hcd as a module. > >> 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)? > Let me paint a more complete scenario. I can leave the device > permanently plugged into a Windows box and it doesn't die due to > activity from the Windows machine. If I leave it plugged in to the > Linux box, by the time I get to it after sun up, it's broken. Broken in what way? How do you know that it is dying due to activity from the Linux machine? Or to put this another way, if you unplug the device from the Linux machine and then plug it back in around noon, when there's plenty of sunlight, does it die then? Presumably the activity from the Linux machine is the same no matter what the time of day. 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
