[Fwd: usbmon trace]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...

Summary: 

      * Device unresponsive, appears not to get "Desktop Mode" command
        from barry library through libusb. 
      * 2.6.27 Kernels with same tools (libusb-0.1.12, barry-0.15) work
        correctly
      * 2.6.28-7, 2.6.28-8 (ubuntu), 2.6.28.4, 2.6.28.7 and 2.9.29-rc5
        all fail to run "btool -t", device never enters "desktop mode"
      * 2.6.28-7, 2.6.28-8 (ubuntu), 2.6.28.4, 2.6.28.7 and 2.9.29-rc5
        all work correctly if "btool -t" is run inside gdb, even at full
        "run speed"
      * Inserting a 500,000 usleep after each bulk write allows btool to
        execute correctly on each Kernel version

Please cc: me on responses. "Paul O'Keefe <paul@xxxxxxxxxxxxx>".  Please
also cc: Chris Frey <cdfrey@xxxxxxxxxxxxxx>, the lead on the Barry
project. 

Attachment: 2.mon.out.bz2
Description: application/bzip


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux