On Wed, 25 Feb 2009, Paul O'Keefe wrote: > All -- > > I have been debugging an issue with a Blackberry Curve (8330) with > Firmware 4.5.0.77. The device is USB connected and my intention is to > synchronize contacts with my address book. > > I have been using the barry package which handles low level device > communication through libusb and into the kernel via the ioctl > interface. BlackBerry devices have one of four modes, JavaLoader, > Desktop, Serial or ipmodem which they can be set. I am trying to utilize > the Desktop mode. > > The barry package includes a variety of tools. My testing has focused on > the btool component which allows low level testing of the device. The > command "btool -t" will discover the device on the usb bus, print the > device identifier and then list all the databases stored on the device. > > With kernel packages of series 2.6.27 the btool -t command correctly > produces a list of databases. Since Kernel series 2.6.28 I have been > unable to communicate to the device without modifying the code. > > I have tried two steps. One was to insert a usb_reset call through > libusb prior to issuing any commands to the device, while a second was > to insert a 500,000 uSec wait after all calls to bulk write. > > I have duplicated testing on both a Pentium Dual core laptop and an AMD > Dual Core x86_64 system. Kernel configuration files are based on the > Ubuntu pre-release for Jaunty. > > After inserting the 1/2 second wait after each bulk write, I get normal > (albeit slow!) performance from the device for operations performed in > Desktop mode. Because the device functioned using the same code under > 2.6.27 (and also functions on a Mac OS-X laptop) and doesn't under > 2.6.28, I feel something has changed in Kernel space that affects either > the timing or guaranty of data delivery to the device. > > I can run the "btool -t" command inside gdb without changing any code > and it performs as it should. Gdb is only adding a bit of latency, thus > my timing hypothesis. > > Attached is a usbmon trace from my box. It goes on and on, but all the > real action happens within the first 21 milliseconds. The command to put > the device into desktop mode makes it out, at least according to the > kernel. Whether it gets to the device or not is another question... The usbmon log shows lots of URBs being cancelled after only 1 ms. Could it be that the btool program thinks that the timeout argument is specified in seconds whereas in reality it should be specified in milliseconds? Alan Stern -- 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
