Date: Tue, 21 Dec 1999 19:28:09 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: hackers@freebsd.org Cc: n_hibma@freebsd.org Subject: Possible solution for USB Ethernet problem Message-ID: <199912220028.TAA07925@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
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 -- ============================================================================= -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" ============================================================================= 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?199912220028.TAA07925>