From owner-freebsd-hackers Wed Dec 22 3:48:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from webweaving.org (dialfwn11.fwn.rug.nl [129.125.32.161]) by hub.freebsd.org (Postfix) with ESMTP id 3330414EFF for ; Wed, 22 Dec 1999 03:48:52 -0800 (PST) (envelope-from n_hibma@webweaving.org) Received: from localhost (localhost [127.0.0.1]) by webweaving.org (8.9.3/8.9.3) with ESMTP id LAA00689; Wed, 22 Dec 1999 11:43:54 +0100 (CET) (envelope-from n_hibma@webweaving.org) Date: Wed, 22 Dec 1999 11:43:54 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Bill Paul Cc: hackers@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 Nice catch (of yet another stupidity in the UHCI controllers). In 1.3.1 they say that 'the preSOF point also prevents a packet that may not fit in the remaining frame period from being initiated.' So the UHCI controller should not start a 64 byte transfer if the MAXP is not set. What happens probably is that the controller does start it and ends up overruning its SOF. The reason for not setting it is that using a MAXP of 32 is more efficient. However, up to now I;ve not seen a device with a packet size of 32 (only 64, 16 and smaller). So switching it on should be no problem. You have a 'Intel 82371SB (PIIX3) USB controller' ? If so, we might be looking at a problem with the 1.0 specification. (please post 'dmesg|grep USB'). I have never had a BABBLE error here, which indicates to me that there was a problem with the 82371SB, which has been solved in the AB/EB. Hm, I'll have to find someone with an 82371SB board and borrow that for a while to get a trace and see what is happening on the wire. This problem should show up with any bulk-64b device if you are right. Cheers, Nick > 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 > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > -- 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