Date: Mon, 20 Dec 1999 14:16:36 +0100 (CET) From: Nick Hibma <n_hibma@webweaving.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@FreeBSD.ORG Subject: Re: USB ethernet hacking Message-ID: <Pine.BSF.4.20.9912201408080.398-100000@localhost> In-Reply-To: <199912192103.QAA03584@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have worked around this for now by hacking usbdi.c so that it polls > the controller interrupt/status register instead of tsleep()ing. I'm not > sure this is the best solution, but it's the only one that seems to work. It isn't. You don't want to be polling for 2msecs for every register transfer. The 2 msecs is due to the framing of the transfers and _nothing_ can be done about that. You'll have to live with that. > Tracing down the error shows that the uhci driver is getting an error > status of 0x500000, which is apparently the logical OR of two error bits: > "babble" and "stall." I have the Intel UHCI spec document and it mentions > these errors, however it doesn't seem to say what causes them, how to > clear them or, more importantly, how to avoid them. If I could just > figure out how to get this thing to handle these "large" transfers, I > would be a happy camper. Please compile your kernel with UHCI_DEBUG and set the uhcidebug in the header of uhci.c to 11 or greater. Then look for uhci_idone. That should show what the error exactly is. If it is babble we have a piece of broken software. If it is NAK then you should set the timeout to a larger value. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9912201408080.398-100000>