> The fact that device A works and device B doesn't on the same > port/cables etc does not eliminate 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.
Agreed. > 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 used the patch provided by Alan to increase the no. of retries. The patch caused the ohci hardware to retry the command 4 times in a row instead of 3 times. So the host controller is willing to talk to device but the device appear to be dead. > What is your key string descriptors ? 3SYSTEM USB POCKET DISK Thanks > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Steve Calfee > Sent: Tuesday, September 26, 2006 10:01 AM > To: linux-usb-devel@lists.sourceforge.net > Subject: Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK > does not work > > >> > >>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 > ------------------------------------------------------------------------- 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
