Date: Fri, 9 May 2003 14:09:39 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: randys@amigo.net Cc: dpageau@infodev.ca Subject: Re: Dual ethernet card Message-ID: <200305092109.h49L9dM7038788@gw.catspoiler.org> In-Reply-To: <20030509092459.U1529-100000@stalker.amigo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 May, Randy Smith wrote: > On Fri, 9 May 2003, D.Pageau wrote: > >> Date: Fri, 09 May 2003 11:07:29 -0400 >> From: D.Pageau <dpageau@infodev.ca> >> To: "freebsd-isp@freebsd.org" <freebsd-isp@freebsd.org> >> Subject: Dual ethernet card >> >> I have a FreeBSD box in 1U Rackmount case, I only have one PCI slot >> availaible (1U) and I need 3 Ethernet interfaces, one is onboard the >> other 2 interfaces should be a dual ethernet card. >> >> Do you have any experience with this kind of interface, which one >> (brand/model) is know to be working fine under FreeBSD. >> > > I've had good experiences with Intel PRO/100 S nics. (It'll get even > better as FreeBSD gets support for the hardware encryption in the nics.) I > have a couple of 2U servers with them and they have run without any nic > related problems. I wish I could say the same. I've got two of these and they have problems when used with recent versions of the fxp driver in -current. Packets of certain sizes get truncated. It is possible to test for the problem by doing ping -c 216 anotherhost ping -c 1696 anotherhost ping -c 3176 anotherhost ping -c 4656 anotherhost My cards work fine until I get to size 3176, but I've seen a report from someone who had problems with all of the above packet sizes. It's fairly easy to get things working again by a simple patch to the driver, but that disables the newer features on these cards. My cards also have a problem at initial power up. When the box is first powered up the cards are not visible to either the BIOS or to FreeBSD. They aren't even visible to Intel's DOS-based diagnostic .exe program. Hitting the reset switch during the boot or logging onto the console and rebooting will fix the problem until the next time the system is powered down. The problem happens in two different systems, one is Celeron-based, and the other is an AMD Athlon-XP. The cards are IBM OEM numbered and I got them fairly cheap, so I don't know if there's anything funny about that particular flavor.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305092109.h49L9dM7038788>