[EMAIL PROTECTED] wrote: > I malloc'ed the firmware memory in the ReadFirmware function. You're > loosing 32k of memory :) Oops. Mea culpa. <snip> > I had the timeout for the Download stuff at 50000. It just didn't work. > I just tried your version, and that doesn't work either. What controller > are you using? Mine is a i815 with usb-uhci on 2.4.6. Should I be trying > this on 2.4.6-ac1? I am using uhci, on 2.4.5-ac1. I will try some other combinations later. <snip> > *grmbl* Doesn't on my box. I keep getting Connection timeouts and Broken > pipes. I've changed my version to match yours (except the GetStatus struct > changes, I don't really like those), with timeout = 100 for all stuff > except the DFUDownload, where I've got a timeout of 5000000. How long does it take to actually produce the failure. IIRC, timeouts are in milliseconds in libusb, and 5000 seconds is quite a long time. > This results in the following: <snip> > DOWNLOADING 1024 Bytes (Block = 4) > Write FW Block 4 failed (-1: error sending control message: Connection timed out)! I saw this before changing the timeouts (where the Block varied). Do you get consistent failures on Block 4? > In my dmesg I see the following: > > hub.c: USB new device connect on bus1/1, assigned device number 21 > usb.c: USB device 21 (vend/prod 0x3eb/0x7603) is not claimed by any active driver. > usb-uhci.c: interrupt, status 2, frame# 1978 > usbdevfs: USBDEVFS_CONTROL failed dev 21 rqt 33 rq 1 len 1024 ret -110 Maybe a HCD guru can interpret this part. > The included code is my current base for the dfu module. I think the > ioctl model should work without a problem, but as I said, I need the > userspace counterpart to go with it before I can test this. I still like the user-space implementation. BTW: Have you got a more recent at76c503a.[ch] implementation than the one on your CVS server? Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: http://lists.sourceforge.net/lists/listinfo/linux-usb-devel