From: Kasberger Andreas > What is still puzzling me is the fact that the host controller stops any communication. > 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 The complete stop is probably a bug in the error recovery code. > 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 IIRC the host controller should repeat any transfer that is responded to with a NAK. But I'm not sure how long it will do this for before signalling an error. The fact that you caused the ring to be expanded several times does rather indicate that you are not waiting for earlier transfers to finish before adding the subsequent ones. You should at least limit the number of in-flight transfers. David -- 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
