[Nut-upsdev] usbhid-ups fails with Belkin F6C120-UNV in nut-2.4.3

[Jon Burgess]

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