> Actually the device is not dead. Not at all. If it were > then the class-specific device reset (which is nothing more > than a USB control transfer) would fail.
Agreed ! I actually meant to say that data path from device to host is somehow broken. The fact that the device always responds to class specific device reset is enough to prove that device is alive. > I think it's significant that the device always fails at > exactly the same spot. That is, one particular command > causes the failure. The device do not fails exactly at the same spot. Early on the device always failed to respond to MODE_SENSE(6). After updating unusal_dev.h to not send MODE_SENSE(6) command, the device failed to generate ACK for READ_10 command and other command. In some instance, I was able to mount and access the files on the disks and the device worked perfectly(no ACK issues). I have also noted that the device either generate ACK or no handshake for OUT 31 transaction. But the device never generated NAK for OUT 31 transaction. Thanks > -----Original Message----- > From: Alan Stern [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 26, 2006 1:21 PM > To: Vivek Dharmadhikari > Cc: Steve Calfee; linux-usb-devel@lists.sourceforge.net > Subject: Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK > does not work > > On Tue, 26 Sep 2006, Vivek Dharmadhikari wrote: > > > 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. > > For some strange reason, the OHCI specification document > doesn't say exactly how the retry mechanism should work. > There is a 2-bit error counter, normally set to 0. It gets > reset to 0 every time a transaction succeeds. When a > transaction fails the counter gets incremented, unless it is > already equal to 2, in which case the host controller returns > an error. > > The spec doesn't say what should happen if the counter is > initially equal to 3. Normally you would expect it to just > stay there, with no change, no errors reported, and unlimited > retries. But apparently your hardware "increments" it to 0, > giving a total of 4 attempts instead of 3. > > > So the host controller is willing to talk to device but the device > > appear to be dead. > > Actually the device is not dead. Not at all. If it were > then the class-specific device reset (which is nothing more > than a USB control > transfer) would fail. But it doesn't fail; it succeeds and > the device continues operating. Until the command is retried... > > I think it's significant that the device always fails at > exactly the same spot. That is, one particular command > causes the failure. It could be that the device doesn't want > to carry out the command -- but we know that it _does_ carry > out the command when running at full speed or using a > self-powered high-speed hub. More likely the bit pattern of > that command string is, for some reason, not received > correctly by the device. Maybe it thinks there's a > bit-stuffing violation when there really isn't. > > However this is sheer speculation. We don't really have > enough information to say why it doesn't work. > > IMO you should just accept that this is hardware problem > which can't be solved in software and won't get better, and > either use that self-powered hub all the time or else use a > different brand of flash memory device. > > Alan Stern > ------------------------------------------------------------------------- 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
