Re: [Nut-upsuser] tracing a problem with newhidups

[Arnaud Quette]

Hi Rodrigo,2006/7/7, Rodrigo Ventura [EMAIL PROTECTED]:
On Thursday 06 July 2006 20:15, Arnaud Quette wrote: a good try, and amount of effort. Sadly, notifications are on the PIPE_INTERRUPTOk, let's do it again.HIDGetEvents() calls libusb_get_interrupt() with size=20 (hardcoded), which
calls usb_interrupt_read(), then usb_urb_transfer(), which setsurb.buffer_length=20, going down the ioctl (as uurb), where the kernel urbstruct gets urb.transfer_buffer_length=20. Then, uhci_submit_interrupt()
checks that field withif (urb-transfer_buffer_length  usb_maxpacket(urb-dev, urb-pipe,usb_pipeout(urb-pipe)))return -EINVAL;
What is the endpoint max packet size? According to /proc/bus/usb/devicesC:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=0mAI:If#= 0 Alt= 0 #EPs= 1 Cls=09(hub) Sub=00 Prot=00 Driver=hubE:Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T:Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=2 Spd=1.5 MxCh= 0D:Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=1P:Vendor=0463 ProdID= Rev= 1.00S:Manufacturer=MGE UPS SYSTEMSS:Product=Evolution
S:SerialNumber=AF3G03062C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 40mAI:If#= 0 Alt= 0 #EPs= 1 Cls=03(HID) Sub=00 Prot=00 Driver=(none)E:Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=20msAssuming that MxPS means max packet size, it seems to be 8, which is
lower than 20, and therefore it looks like the EINVAL error comes fromthere. Am I going in the right direction this time?your guess seems right.The best to validate your guess is to modify the 20 to 8 in get_interrupt() and to recompile nut.
Let me know the result, and I'll fix that for 2.0.4-pre2 next week. If something is not working, you can try to reset the communication: power
 off the UPS, then unplug its power cable, wait (at least) 10 seconds and replug/restart all.Well, that's something I'd like to avoid, since all the institution serversare fed by the UPS.
I understandArnaud-- Linux / Unix Expert - MGE UPS SYSTEMS - RD DptNetwork UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/OpenSource Developer - http://arnaud.quette.free.fr/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser

[Nut-upsuser] tracing a problem with newhidups

[Rodrigo Ventura]

Hi. I'm having trouble with nut-2.0.3 on a linux kernel 2.4.32 machine and a 
MGE Evolution 3000. The problem is that I'm getting the following message, 
repeatidly, on dmesg:

usbdevfs: usb_submit_urb returned -22

(-22 means -EINVAL)

I traced the problem with newhidups -DD auto and found out that the -22 
error appears in a line none (-22) of the output as:

--
upsdrv_updateinfo...
Waiting for notifications...
 none (-22)
entering string_to_path()
parsing UPS
Looking up UPS
--

The function calls in userspace are:

[newhidups.c] upsdrv_updateinfo()
   [libhid.c] HIDGetEvents()
  [libusb.c] libusb_get_interrupt()
 [libusb] usb_interrupt_read()
[libusb] usb_urb_transfer()

In the usb_urb_transfer() function one can find that

--
urb.number_of_packets = 0;  /* don't do isochronous yet */
urb.usercontext = NULL;

ret = ioctl(dev-fd, IOCTL_USB_SUBMITURB, urb);
--

and in the kernel code of linux/drivers/usb/host/uhci.c:

--
static int uhci_submit_urb(struct urb *urb)
[...]
case PIPE_ISOCHRONOUS:
if (urb-bandwidth == 0) {  /* not yet checked/allocated 
*/
if (urb-number_of_packets = 0) {
ret = -EINVAL;
--

So it seems that setting number_of_packets to zero is directly related with 
the kernel error.

What is going on here? Is it a bug in nut?

Cheers,

Rodrigo

-- 

*** Rodrigo Martins de Matos Ventura [EMAIL PROTECTED]
***  Web page: http://www.isr.ist.utl.pt/~yoda
***   Teaching Assistant and PhD Student at ISR:
***Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, PORTUGAL
*** PGP fingerprint = 0119 AD13 9EEE 264A 3F10  31D3 89B3 C6C4 60C6 4585

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser