From owner-freebsd-hardware  Fri Mar 22 08:10:45 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA13138
          for hardware-outgoing; Fri, 22 Mar 1996 08:10:45 -0800 (PST)
Received: from boom.vars.com (boom.BSDI.COM [205.230.226.129])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA13132
          for <freebsd-hardware@freebsd.org>; Fri, 22 Mar 1996 08:10:40 -0800 (PST)
Received: from boom.vars.com (localhost.vars.com [127.0.0.1]) by boom.vars.com (8.7.3/8.6.5) with ESMTP id IAA07807; Fri, 22 Mar 1996 08:57:43 -0700 (MST)
Message-Id: <199603221557.IAA07807@boom.vars.com>
To: Juha Inkari <inkari@snakemail.hut.fi>
Cc: lyndon@orthanc.com (Lyndon Nerenberg VE7TCP), freebsd-hardware@freebsd.org
Subject: Re: 3c590 
In-Reply-To: Your message of "Fri, 22 Mar 1996 11:41:27 +0200."
             <199603220941.LAA23453@lk-hp-20.hut.fi> 
Mime-Version: 1.0
Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=05448C39
Content-Transfer-Encoding: 7bit
Date: Fri, 22 Mar 1996 08:57:33 -0700
From: Eric Varsanyi <ewv@boom.bsdi.com>
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


>
>> have the problem. (Anything after revision A boards should be fine.
>> Mine are revision C.)
>
>> The bug is documented in the _PCI/EISA Bus-Master Adapter Driver
>> Technical Reference_ (3COM part number 09-0681-001A).
>
>Thanks. My card says it's:
>3C590C
>     ^
>03-0046-001 REV D
>        ^^^     ^
>
>The ^ marked are handwritten. Would this actually be a bug in the vx
>driver, then ?

3COM changed their minds on this (after producing the tech manual)...
the new party line is that you should install their S/W workaround.
As far as I can tell they have no plans to fix this bug, no one
I've heard of has a fixed card.

The problem is that on 10mbit nets rx packets that overrun the FIFO
may be silently corrupted (instead of dropped). Their recommended
solution is quite complex but it basically keeps track of how full
the FIFO has gotten and drops all packets that may have overrun
the end.  I implemented a simpler version of their fix in our
driver, it was only a few lines of code. In general the size of
the FIFO's on the broken cards is at least 32K so it doesn't hurt
to reserve the top 6K for 'overrun protection'.

- -Eric

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBMVLN7DxFdSMFRIw5AQH2HAQAkS8xU6xwosKUoTFdT1x4IfSRA5cojkuT
8xB6Vvw4qkvlaRwzI3Mcs0/rlhTS7zh1LBeGLzx3Fafhce89Fgi/bnDswTmowo3H
TFDpOGbfil4+kKB663UG5WdwTd7NQSWJtwbBq7UMK7e3LO+saatHNFLdIrJ7fyMI
CscgHcXSYV4=
=BC2s
-----END PGP SIGNATURE-----