From owner-freebsd-hackers Tue Dec 21 17:26: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E3E3D14DBD; Tue, 21 Dec 1999 17:26:01 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA85168; Tue, 21 Dec 1999 17:25:52 -0800 (PST) Date: Tue, 21 Dec 1999 17:25:50 -0800 (PST) From: Julian Elischer To: Bill Paul Cc: hackers@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: Possible solution for USB Ethernet problem In-Reply-To: <199912220028.TAA07925@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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