Date: Mon, 20 Dec 1999 15:09:00 +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.9912201453220.398-100000@localhost> In-Reply-To: <199912192103.QAA03584@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> However that's not my biggest problem. My biggest problem is getting > transfers over 1100 bytes or so to work reliably. My initial scheme > for transmitting and receiving packets was to set up asynchronous > transfers with callbacks. Packets are sent over bulk transfer endpoints > (one for RX, one for TX). For TX, I would set up a transfer and initiate > it, then wait until the callback is called to free the mbuf containing > the packet data. This seemed to work, but only for transfers around > 1000 to 1100 bytes or so. Trying to transfer packets of 1200 bytes or > more always seemed to yield an "IOERROR" error. I switched the packet > transmission code to use synchronous transfers (i.e. waiting for the > transfer to complete before moving on) and this seemed to help: I could > now get transmissions up to 1500 bytes to work without errors. This sounds to me like the device wants the xfer all in one go, occupying the best part of two USB frames. Why the switch to synchronous transfers changes things I don't know, but it might be coincidental. > However, I have the same problem now with received packets: trying to > receive a frame larger than 1100 bytes also causes an IOERROR, however > I can't use a synchronous transfer here since that would cause the kernel > to freeze in its tracks waiting for a packet. Would it be possible to limit the MTU length on the ethernet network to something less then 1000 bytes (the USB frame length)? Just to make sure you get the rest working before addressing this problem. > 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. BABBLE means that the device is transmitting more than it should be. It indicates a protocol or firmware error. You'll have to reset the device to bring it into a known state. At that point, the total length is not valid. > I put a copy of my current code at: > > http://www.freebsd.org/~wpaul/ADMtek/USB/4.0 line 928: USBD_SHORT_XFER_OK on outgoing transfers is useless. 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.9912201453220.398-100000>