On Wed, 4 Mar 2009 21:33:24 -0500, Chris Frey <cdfrey@xxxxxxxxxxxxxx> wrote: > @@ -40,8 +40,6 @@ > C Bi:1:002:3 0 12 = 00000c00 06ff0006 00000000 > S Ci:1:002:0 s 80 08 0000 0000 0001 1 < > C Ci:1:002:0 0 1 = 01 > -S Co:1:002:0 s 00 09 0001 0000 0000 0 > -C Co:1:002:0 0 0 > > This is the usb_set_configuration() that's missing in the timeout version. > > S Co:1:002:0 s 02 01 0000 0083 0000 0 OK > @@ -49,46 +47,6 @@ > S Bo:1:002:4 -115 24 = 00001800 07ff0007 52494d20 4465736b 746f7000 00000000 > C Bo:1:002:4 0 24 > > S Bi:1:002:3 -115 16384 < > -C Bi:1:002:3 0 44 = 00002c00 08050007 52494d20 4465736b 746f7000 00000000 00000000 01000400 > -S Bi:1:002:3 -115 16384 < > C Bi:1:002:3 0 12 = 00000c00 13050100 00000000 > So, unless I miss my guess, it looks like somehow the device thinks it has > already sent the data, and sends the sequence packet when we're expecting > data. Barry then asks for the actual data, and we timeout, because the > device has nothing to give. OK > It looks like a bulk message is being dropped or ignored somewhere > along the way. > > Thoughts? This is not how USB works. Unless I misunderstood you, you think it's some kind of overcomplicated Ethernet. But in reality the properties of the bus are completely different. You may rest assured in this case that the device simply did not send the data. Note though, the packet loss is possible inside the device. For example, consider a device which only has one buffer that can only hold one message (remember that a USB device cannot send anything to the host on its own accord, and must be polled by the host). If the host does not schedule a transfer to fetch it, next message will overwrite the previous one. It's difficult to imagine Blackberry to be this retarded. It's more common on USB devices made around 8-bit PICs. But who knows. -- Pete -- 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
