From owner-freebsd-current Mon Apr 5 18:30:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by hub.freebsd.org (Postfix) with ESMTP id D979515573 for ; Mon, 5 Apr 1999 18:30:30 -0700 (PDT) (envelope-from wpaul@ctr.columbia.edu) Received: from startide.ctr.columbia.edu (wpaul@startide.ctr.columbia.edu [128.59.64.52]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id VAA23271; Mon, 5 Apr 1999 21:28:15 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) Received: (wpaul@localhost) by startide.ctr.columbia.edu (8.9.1/8.6.4.788743) id VAA21701; Mon, 5 Apr 1999 21:28:13 -0400 (EDT) Message-Id: <199904060128.VAA21701@startide.ctr.columbia.edu> Subject: Patched RealTek driver -- please test To: current@freebsd.org Date: Mon, 5 Apr 1999 21:28:12 -0400 (EDT) Cc: bright@rush.net, mrt@notwork.org, shocking@prth.pgs.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, today (and over part of the weekend) I ripped the RealTek driver apart and put it back together again, this time in a hopefully working form. The temporary patch version is at the following locations: http://www.freebsd.org/~wpaul/RealTek/test/2.2 source for FreeBSD 2.2.x http://www.freebsd.org/~wpaul/RealTek/test/3.0 source for FreeBSD 3.x/4.x If you've been having problems with RealTek 8139 cards, please try this version and let me know if it makes a differences. All of the main changes are in the transmit code. I also think I know why the transmitter was getting wedged. The sort answer: I'm a twit. The long answer: when ifinit() was changed so that it warned about ifq_maxlen not being set by the driver, I went in and set it to RL_TX_LIST_CNT - 1, which is approximately what I'd done for the other drivers. However the RealTek only has four transmit 'descriptors' which means the ifq_maxlen for the interface was being set to the ridiculously low value of 3. This causes transmissions of large packet sequences to quickly fill up the send queue. (For example, try doing a ping -s 8100 and see if it actually works. My bet is that it won't, because this will generate a series of six or seven frames in rapid succession, and after the first 3 or 4, the queue fills up.) In addition to fixing this, I also re-wrote rl_start() and rl_txeof() to hopefully be a little simpler and less brain damaged. I still need to fill in rl_txeoc() correctly, but once I know for sure that I've fixed all the major problems, I can probably do that in an hour or two. I experimented with this driver version using a FreeBSD 2.2.7 server and a FreeBSD 3.0 client (sorry, it's all I had) and I couldn't get NFS to hang. I also bombarded the server with a TCP stream from the client while the NFS test was running and it didn't lock up. -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 ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message