Re: coping with poor usb implementations

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

 



On 17 Dec 2011, at 16:52, Alan Stern wrote:

> Please use Reply-To-All so that your messages go to the mailing list as 
> well as to me.
I realised that after replying. I
> 
> 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:
>>> 
>>> [snip]
>>> 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?
This blog post http://bit.ly/ssHC1Z
> 
> 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.
I don't know what's going wrong in detail. It looks to me more like a timing issue (communications from the USB host - ie linux box - overwhelming the device, which eventually runs out of memory somewhere (eg runs out of stack, consumes too much memory for all functions to work in some way.
> 
>>> [snip]
>>> 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.
Presumably these devices have a usb connector on one end and an rs232 connector on the other. I had in mind the situation where a hardware manufacturer wires up their own 'solution'.
> [snip]
> 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.
Can you elaborate on that a bit?  I cannot seem to get uchi_hcd to unbind from anything. I'd assumed that rmmod would work (it doesn't, yet, but the kernel config has the uchi_hcd driver compiled in, rather than as a module. I'm in the process of trying a module based driver). Is there some other mechanism?
> 
>>>> 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?
If I unplug the linux box and plug the usb host connector into the wintel box, it will not communicate properly with the device. There's clearly some sort of communication going on, but the protocol is not working as it should. 
> 
> 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.
It's may not be due to low power, per se, but just the boot sequence of the controller introducing timing problems. I don't know. If I plug in the linux box after the inverter's controller has come up, everthing's fine (ish: it may still be necessary to use low level retries to get data out of the device, but that's considered 'normal' by the author of the software).

Today, I thought that I'd managed to pull the connection out of the linux box before the controller had got its knickers in a twist. Unfortunately, although there were many fewer connect/disconnect cycles (~370), the log shows that I was late as the device had already settled down before I disconnected it.

Tomorrow I'm going to reconfirm that windows (xp) is ok through the power on sequence for the controller. I'm also going to try to pull out the uhci_hcd driver.  If you can tell me how to unbind the driver, that would be great. These latter tests will have to wait for another day.  I'm not inclined to trial different device reset mechanisms as it involves disconnecting the mains from the inverter.
> 
> Alan Stern
> 
Tim--
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