On Wed, Mar 04, 2009 at 06:01:58PM -0500, Chris Frey wrote: > Following your advice, I also tested 2.6.29-rc7, and the same timeout issue > occurs there. > > I've found that if I force btool to call libusb's usb_set_configuration() > even when it is not necessary, then this fixes the timeout. More information on this bug. I tried comparing usbmon captures of a successful and timeout sequence, and here's the diff (diff -u working timeout): @@ -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 C Co:1:002:0 0 0 S Co:1:002:0 s 02 01 0000 0004 0000 0 @@ -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 00000 000 01000400 -S Bi:1:002:3 -115 16384 < C Bi:1:002:3 0 12 = 00000c00 13050100 00000000 Here, the first missing packet is the data we're looking for, in order to enter the Blackberry's Desktop mode. The next packet (00000c00 1305...) is what we call a "sequence" packet, and comes after the actual data. Barry will eat a sequence packet and ask immediately for actual data if it hasn't already received it. 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. It looks like a bulk message is being dropped or ignored somewhere along the way. Thoughts? - Chris -- 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
