Of course the ISA-ethernet-cards still work, but people are asking for PCI-based ones. The author of many (if not most) ethernet- drivers said the following some time ago (unfortunately I have not managed to contact him about new information):
From: Donald Becker (becker@cesdis.gsfc.nasa.gov) Subject: PCI ethernet cards supported?The LANCE code has been extended to handle the PCI version. I hope to get the PCI probe code (about a dozen extra lines in the LANCE driver) into the next kernel version. I'm working on the 32 bit mode code. I haven't yet started the 21040 code.
I'll write drivers for the PCnet32 mode and the DEC 21040. That will cover most of the PCI ethercard market.
file://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
In the new testkernels of 1.1.50 and above, the AMD-singlechip ethernetadapters are supported. With a pentium, they ought to then see 900K/second ftps +(assuming an NCR PCI scsi controller) at about 20% cpu load. (AMD Lance).
Anything based on the AMD PCnet/PCI chip should work at the time being. In the US the Boca board costs under US$ 70
Geoffry Coram reported in the news that he got his 3com 590 TPO to work. He had to get the alpha driver from http://cesdis.gsfc.nasa.gov/linux/drivers. Other drivers would be there as well. Note http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
Donald Holmgren said he successfully attached his DEC DE435 (PCI) card to the local network on thin coax (BNC). The DE435 driver checks the twisted pair connection first, then switches to the alternate port (jumper selectable as AUI or BNC) if the 10BaseT port fails.
Jim Cusick uses the Boca BEN 1PI card on a thin coax network. It works just fine. You might want to check out: http://cesdis.gsfc.nasa.gov/linux/misc/boca-failure.html for details on the early failures of this card. My second card, after sending one back for replacement, was marked "PN 4186". The old one that did not work was "PN 4185". Mandate this newer model when you order from you vendor. At $ 70, the card is a good deal.
Dave Platt recommends to stay off the Boca BEN1PI card at all costs. It would be unreliable due to design flaws, and Boca seems unable to really fix the problem. The 3Com 3c590 "Vortex" PCI card is available in a combo version (10BaseT, thin coax, and AUI). The Linux driver for this card is not yet part of the release kernel, but is available from http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html and can be patched into the later 1.2.x kernels (as well as 1.3.x) without much difficulty. The Linux driver does not support the interface autodetect feature of this card - you must use the DOS utility to configure the card for the interface you wish to use (thin coax in this case). Once you've done that, the Linux driver will use the correct interface.
He has been using a 3c590 for several weeks, and it is working fine.
Dave Kennedy said he got two of the above Boca boards and they work fine under light load, but under heavy work like ftping two 16M files into both directions, they failed. He sent the boards back to Boca for a hardwarefix. After they soldered a couple of things (diodes/resistors) onto the card and sent them back, the cards worked fine regardless of load. The two cards have been in 7/24 use in two P90 systems without problems for 6 months now.
Craig does not recommend it since Boca seems not to follow the AMD specs but he has been running them for 2 weeks without problems. He tested his NFS performance and has been moving large files to and from server (16M, 8M). He also tried to do all his workin localy using his data files mounted by NFS and has had no problems. Performance seems to be 100 percent better (wrt to NFS performance) over his NE2000 ISA board. (editors note: but so would probably have been the ISA SMC Elite Ultra?)
Someone on usenet mentioned ht used the 3Com-3C590-TPO (EtherLink III - PCI). He had to get the "3c59x.c" driver and "vortex.patch" to make it work with his 1.2.8 Linux kernel.
The DEC435 PCI NIC is said to work great with the drivers included in the Slackwaredistribution - I'd say they are in the standard-kernel?