Date: Tue, 21 Dec 1999 17:25:50 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: Possible solution for USB Ethernet problem Message-ID: <Pine.BSF.4.10.9912211724070.44225-100000@current1.whistle.com> In-Reply-To: <199912220028.TAA07925@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
we were usug both IHCI and UHCI which is why we didn't mention it. we DID have a problem one one of them (which seemed unrelated) but I can't remember which. It was reported by other people around the same time so we didn't connect it with our driver. On Tue, 21 Dec 1999, Bill Paul wrote: > Previously I mentioned that I was having trouble sending full sized > ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus > eval board. The problem turned out to be in the uhci driver, however > I'm not certain exactly how to incorporate my fix. > > The problem I was seeing was that large frames would trigger babble > errors, which would cause an endpoint halt and wedge the RX or TX pipe. > Julian brought up another driver written by Doug Ambrisko which appeared > to be able to transfer 1500-byte frames without any trouble. However, > neither he nor Doug bothered to mention if their test machines had UHCI > or OHCI hubs. Given what I've learned, I suspect they were OHCI. > I downloaded a copy of the Intel UHCI spec document from > ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it > for a while. On page 17, it describes the MAXP bit in the command > register. The description reads: > > Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the > maximum packet size that can be used for full speed bandwitdh > reclamation at the end of a frame. This value is used by the > Host Controller to determine whether it should initiate another > transaction based on the time remaining in the SOF counter. Use > of reclamation packets larger than the programmed size will > cause a Babble error if executed during the critical window at > frame end. The Babble error results in the offending endpoint > being stalled. Software is responsible for ensuring that any > packet which could be executed under bandwidth reclamation be > within this size limit. > > The ADMtek part is documented to use 64-byte USB packets for frame > transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the > MAXP bit in the command register when it starts the controller running. > I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the > ADMtek ethernet controller sends and receives 1500-byte frames with > no problems. > > The question is, how should this be handled? Should the UHCI_CMD_MAXP > bit be set all the time, or just when high speed devices are attached > to the bus? The Intel manual seems to imply that it's safe to leave this > bit enabled all the time, however I can't test this since I only have > the one USB device. Also, should something similar be done with OHCI > controllers, or do they handle this sort of thing correctly? > > -Bill > > 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.10.9912211724070.44225-100000>