Date: Mon, 5 Apr 1999 22:07:45 -0500 (CDT) From: <mestery@visi.com> To: Bill Paul <wpaul@ctr.columbia.edu> Cc: current@FreeBSD.ORG Subject: Re: Patched RealTek driver -- please test Message-ID: <Pine.GSO.4.02.9904052206010.21360-100000@isis.visi.com> In-Reply-To: <199904060128.VAA21701@startide.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Bill, Just tried the new Realtek driver with 4.0, and it works MUCH better. I was seeing weird NFS transmit errors with UDP, and the ping you suggested below did not work with the old driver (it reported an out of buffer space message and didn't transmit any packets). With the new driver, the ping works, and nfsv3 with UDP works flawlessly. Also, ftping into my machine with the Realtek used to yield a max of 66K per second. Now I see closer to 2MB per second. Looks good so far! Thanks! -- Kyle Mestery StorageTek's Storage Networking Group Protect your right to privacy: www.freecrypto.org On Mon, 5 Apr 1999, Bill Paul wrote: > 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 <some host> 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.02.9904052206010.21360-100000>