On Sat, 7 Jul 2001, Brad Hards wrote:
<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.
uhci doesn't work for me either. I know it IS possible to get working with
this device, since it does work under windows.
> > *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.
True. Point is, the timeout doesn't TAKE 5000 seconds, it quits way before
that. I wouldn't have any problems with timeouts if it waited 5000
seconds.
> I saw this before changing the timeouts (where the Block varied). Do you get
> consistent failures on Block 4?
Nope. It differs. Sometimes it's only 2, sometimes 4, I've had it
succeeding if I ignore the errors for DFUDownload. I just don't want to do
that.
> > 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.
I hope so.
> > 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.
So do I. Point is, usbdevfs/libusb doesn't seem to give me enough leeway
in getting it working. It looks like the kernel is the way to go. That
means I can tweak enough to get it working. I think the implementation
I've chosen tries to make sure it doesn't waste memory, and will work well
enough. With a little work of course.
> BTW: Have you got a more recent at76c503a.[ch] implementation than the one on
> your CVS server?
Nope. I've been fooling around with the dfu stuff up till now. I still
haven't had it get that firmware loaded yet.
Regards,
Bas Vermeulen
--
"God, root, what is difference?"
-- Pitr, User Friendly
"God is more forgiving."
-- Dave Aronson
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
