On Sat, 2010-03-20 at 17:02 -0400, Charles Lepple wrote: > On Mar 20, 2010, at 3:19 PM, Jon Burgess wrote: > > > It appears that this UPS is a low speed device and the USB standard > > seems to say these only support transactions of up to 8 bytes in > > length > > > > usb 7-1: new low speed USB device using uhci_hcd and address 2 > > > > There are a few mentions of 8 bytes in the lsusb output for the > > device: > > I haven't done much work with usbmon - is it showing the size of the > transaction as requested by the application, or what goes out over the > wire?
Somewhere in between, the log messages come from the kernel but at an intermediate level in the generic request handling code and not showing exactly what happens on the wire. For example, when usbhid-ups reads the report descriptor: 0.171001 HID descriptor length 801 0.276999 Report Descriptor size = 801 usbmon reports this as a single request: ffff88002b799d80 593521102 S Ci:7:002:0 s 81 06 2200 0000 0321 801 < ffff88002b799d80 593626095 C Ci:7:002:0 0 801 = 05840904 a1010586 0926a102 85017508 95016500 55001500 26ff0009 40b10285 For more details see the kernel Documentation/usb/usbmon.txt or http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/usb/usbmon.txt;hb=HEAD > Along those lines, what kernel version are you using? I tried the following two Fedora 12 kernels with no difference between them: kernel-2.6.31.12-174.2.22.fc12.x86_64 kernel-2.6.32.9-67.fc12.x86_64 > Are you using > libusb-0.1.x, or the 0.1 compatibility layer from libusb-1.0? libusb-0.1.12-22.fc12.x86_64 > Several years ago on the linux-usb list, it was often pointed out that > the kernel was supposed to honor the wMaxPacketSize field, and > fragment the requests accordingly. While this was suggested for > performance reasons (fewer round trips between user and kernel space), > it should still hold true for less frequent transfers. In this case we are reading the data, I don't know if there is much the kernel can do to fragment this, I don't see any concept of an offset field when reading the report. Surely we are expecting the other end to fragment any response appropriately. Jon _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
