Date: Sat, 17 Oct 1998 12:16:04 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: 2nd call for testers for PNIC driver Message-ID: <199810171616.MAA20232@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
This is a second call for testers for the Lite-On PNIC driver (if_pn). My first call resulted in a couple of respondes, most of which were in the form of "I'll have one of these boards to try soon and I'll get back to you" and only one of which was of the form "I tried it and here's what happened." (And special thanks to Mark Tinguely for being that one.) Here's what's changed since the first announcement: - Fixed the programming of the multicast filter in the 2.2.x version of if_pn.c. When I converted the 3.0 driver to 2.2.x, I left out a few things from pn_ioctl(). - Rearranged the interrupt handling and transmission a bit to avoid some possible infinite loop conditions where the interrupt handlers would do the wrong thing and retrigger interrupts over and over again. - Turned off store and forward mode and instead set the tx threshold to 72 bytes. This improves performance quite a bit at 100Mbps. I still don't have my regular test machines back (hopefully I will on Monday) but in the meantime I've kludged together another testbed. Transmit performance with the PNIC seems a little slow: with other NICs like the ThunderLAN and the 3Com 3c905/3c905B, I could get data rates of 11.3MB/sec to 11.4MB/sec using ttcp. Heck, even the RealTek would do 11MB/sec. The PNIC seems to be barely able to reach 10MB/sec if you push it really hard on a fast machine. The main test machine I'm using now is a Dell PowerEdge 2300/400 SMP system with dual PII 400Mhz CPUs and 256MB RAM (with a CAM binary snapshot release from a couple months ago). Using Lose NT Server with service pack 1 and the LinkSys drivers that came with my test card, I can get about 8.5MB/sec over FTP. My driver with an SMP kernel achieves pretty much the same performance. One thing that's a little strange is that if I run a uniprocessor kernel on the same hardware, transmit performance increases a bit from 8.5MB/sec to 10MB/sec. As an aside, I spoke with Greg LaPolla from LinkSys on the phone earlier this week and learned that when LinkSys first approached Lite-On about using their PNIC chips on LinkSys adapters, LinkSys insisted that they would only deal with Lite-On if the PNIC were made available without NDA for the benefit of free OS programmers/users or else they would get up and walk right out the door. He implied that the PNIC engineers were opposed to this but Lite-On eventually gave in. Greg has also told me there will be an official link from the LinkSys web server to www.freebsd.org pointing to the FreeBSD driver once it's ready for prime time, so everybody get your acts in gear and help me test this sucker. There is already an unannounced FreeBSD page at http://www.linksys.com/support/solution/nos/freebsd.htm. So anyway, go to http://www.freebsd.org/~wpaul/PNIC and read the instructions about how to install the PNIC driver. The source is at: http://www.freebsd.org/~wpaul/PNIC/3.0 source for FreeBSD 3.0 http://www.freebsd.org/~wpaul/PNIC/2.2 source for FreeBSD 2.2.x So far, I've learned from Mark that he has one pathological P90 system with a Neptune chipset and a NetGear FA310TX D1 card which locks up periodically, however I have been unable to reproduce his problems on my machines and he says the card and driver seem to work okay on other systems that he's tried. I've also received one problem report that was resolved by putting the card in a different PCI slot: please make sure that you put the LinkSys adapter in a bus master PCI slot when you install it. Note that this driver still does not support the PNIC's internal transceiver since I don't have a card that uses the internal transceiver for testing. The LinkSys, NetGear, Matrox and I think D-Link adapters that use the PNIC all use external PHYs through the MII bus, so for current cards this is not a problem. I did some more testing with the transmit list base address register (CSR4) and am convinced that the chip is broken in that after setting CSR4 the first time after a software reset, trying to change it later doesn't work. The driver still uses the 'kludge descriptor' workaround for this problem. I spoke with Lite-On engineers about this at the same time I spoke with Greg, however I haven't gotten a conclusive answer back yet as to whether this is really a chip errata or stupidity on my part. Never having programmed a real tulip chip before, it may very well be that this is intended behavior. (Though if it is intended behavior, it's really stupid intended behavior.) On a separate note, I am still looking for a vendor for cards that use the Winbond WB89C840F chip so that I can complete my Winbond driver. If anybody knows where I can order a board with one of these chips, please e-mail me. Note: that's _840_ not _940_. The 940 is a 10Mbps-only NE2000 clone. The 840 is a dumbed-down 10/100Mbps tulip clone. On another separate note, I'm planning to import the RealTek driver into FreeBSD-current soon now that 3.0 is going out the door. So far I've only gotten a couple of reports about this driver but they've been positive. I've learned of quite a few cheap cards that use the RealTek 8139 chip. Go to http://www.freebsd.org/~wpaul/RealTek if you have one of these and want to be a tester. -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?199810171616.MAA20232>