On Wed, Feb 05, 2014 at 07:33:15AM +0000, Kasberger Andreas wrote: > Hello Peter, > > many many thanks for your long and detailed answer. > > > On the protocol design: > > > > First, using CDC-ACM means sacrificing all structured communication > > offered by the USB packet bus and settling for such primitive use of > > USB is not a decision that should be made lightly. Almost all > > applications can benefit quite significantly both in end-user > > usability and in ease of implementation from an application-specific > > protocol which takes advantage of what USB offers. > > > Yes you are absolutely right. No the best idea. The usage for this protocol is to make firmware updates. In normal life it is a simple keyboard. And sending out bulk messages is the great advantage of CDC/ACM > > > What is still puzzling me is the fact that the host controller stops any communication. Perhaps looking at the USB mon trace would help? I'm wondering if the driver is continuing to submit URBs even though the next ones are NAKed? http://lxr.free-electrons.com/source/Documentation/usb/usbmon.txt It could also be a problem with the xHCI cancellation code. ISTR that we have an issue in the driver where if no URBs get completed, the dequeue pointer gets left on the last TRB that completed, and we keep expanding the rings indefinitely. When you turn on xHCI debugging (either through CONFIG_USB_XHCI_HCD_DEBUG or by running `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control`) do you see messages about URB cancellation? > That means there is really electrically no communication (bulk_out) from HC to device anymore. It seems that the host controller has shut down communication port to one particular device. unbind and bind host controller will solve the problem Do you have auto-suspend enabled for the device? Perhaps the CDC-ACM driver is suspending the device because there's no reader? You can see if auto-suspend is enabled by finding the device in /sys/bus/usb/devices and seeing if power/control is set to 'auto'. > But anyway I will try do my best to find out the root cause of mis-communication between between both sides. > > > > You mention device-side buffering and that the device at some point > > can't accept anything more from the host. With USB this means that > > you must ensure that the host will know when it must not send more. > > > I thought sending NAK as response for each package is the correct way to tell the host "not now but maybe later.Please try again". After the internal device queue is not completely full namyore the comunication is done in normal way. But after some time HC stops completely any communication. > In real life it means a huge firmware update takes long time and so it could happens the internal device queue is full. But a broken firmware update is a bad thing > > > > The USB way to do this, were you using an application-specific > > protocol instead of serial port simulation, would be to stall the > > endpoint. Unfortunately CDC-ACM doesn't allow doing that. > > Ok. I will think about this if another way is possible > > > > So you have to include some kind of in-band signalling for this. :\ > > > > This is just one reason why ACM is a poor choice for when you need > > structured communication. > > > Anyway many many thanks for your precious time and detailed answers. > > My conclusions and todo : > > 1. Thinking about design > 2. Still try to find out the main reason why host controller shutdown connection > > Arrrghhh Just saw also USB 2.0 has some problems. Host controller is resetting after some hours but not getting in work state again. By USB 2.0, do you mean your device under an EHCI host doesn't work as well? There may be USB 2.0 only ports under your xHCI host, and the best way to find out which host you're under is to run `sudo lsusb -t`. Sarah Sharp -- 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
