Date: Wed, 22 Dec 1999 11:43:54 +0100 (CET) From: Nick Hibma <n_hibma@webweaving.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@freebsd.org Subject: Re: Possible solution for USB Ethernet problem Message-ID: <Pine.BSF.4.20.9912221120090.339-100000@localhost> In-Reply-To: <199912220028.TAA07925@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9912221120090.339-100000>