>> >>Hi >> >> > hub was self powered, it indicates either your device took >> > too much VBUS current, your host could not supply enough vbus >> > power, your host transceiver has a problem, OR you have a >> > major fussy device in receiving data. >> >>We have couple of other 1.1 devices who works with our system in bus >>powered mode. Obviously for such devices, the host could supply enough >>vbus power and host transreceiver did not have any problem. >>
The fact that device A works and device B doesn't on the same port/cables etc does not elliminate the possibility of a VBUS power problem. All devices use different amounts of power, have different needs on vbus rise times, and even different +- voltage level requirements on the data lines. If everything was in spec you would not be having problems. >> > What did your bus analyzer say in this case? Full speed is >> > much more forgiving than high speed. >> >>The analyzer indicated that the device failed to generate ACK for >>certain CBW (31 byte OUT transaction) three times in row. That caused >>ohci driver to reset the device. >> The "no response" is actually quite a clever part of the spec. The problem is what does one end of a communication do if there is a detected error? If something bad is going on, the worst thing that you can do is try to send on the problem data path, so sending a hypothetical "ERR" PID would just cause more problems, like what if the "ERR" PID was lost? So the proper response from either end of a communicaton with a detected problem (such as no sync, CRC, bad PID etc) is no response. All device hardware is supposed to automatically check things like PID, CRC, EOP etc and then respond with ACK if the data was received and it is ready for more or NAK which means data is received correctly but the device cannot handle it right now. If there is no response, the hardware will retry quickly a few times but then give up and let higher level software deal with it (such as resetting the device). In your case there is either a major data path problem and data cannot be passed to the device OR your device is dead and cannot respond to anything. I had a HS USB flash drive that would fail during enumeration as a full speed device about 5% of the time. A bus reset would not recover the device. A port power off then on would get it started again. I don't remember the brand of that key, What is your key string descriptors, maybe I will remember if that is the flaky device if I have a name to remind me. Regards, Steve ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
