On 17 Dec 2011, at 21:37, Alan Stern wrote: > On Sat, 17 Dec 2011, Tim Coote wrote: >>> [snip] >>> What makes you think so? >> This blog post http://bit.ly/ssHC1Z > > That blog post has no apparent connection with your problem. It says > nothing about multiple disconnect messages appearing in the system log. No. But it does describe how the host drivers can confuse devices. And my experience of such devices is that, for instance, they can be swamped with error conditions that causes a stack overflow. Any I'm hypothesising that's what's happened here. > >> 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. > > If you want, you can view the USB communications directly, using either > usbmon or wireshark. Thanks for these. I hadn't realised that wireshark could do this. > >>>> [snip] >> 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'. > > The same chips are used in both situations. The hardware manufacturers > who wire up their own "solution" buy chips from the same vendors who > sell the USB/RS232 converters. Indeed. And then write their own drivers, which are typically only tested with windows. I've now reconfirmed that all's ok if I simply leave the windows box connected all night until after the device boots. > >>> [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? > > Yes, there is: > > echo X >/sys/bus/pci/drivers/uhci_hcd/unbind > > Replace X with the correct name of the UHCI device for the bus your > device is plugged into -- this will be one of the file names in the > /sys/bus/pci/drivers/uhci_hcd directory, such as 0000:00:1d.1. > > To rebind the controller, use the same command but replace "unbind" > with "bind". Thanks. This does seem to work. However, this did not solve the problem the first time (I unbound what I thought was the correct device, but I can see that it could simply be the wrong one, so I'm going to disable them all tonight. Are there any instructions on how these types of commands work. I've found something on lwn, but it misses the context of what the different connections can be. > > 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
