Skip site navigation (1)Skip section navigation (2)
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-hardware" 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>