From owner-freebsd-hackers  Fri Sep 26 07:25:48 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA06999
          for hackers-outgoing; Fri, 26 Sep 1997 07:25:48 -0700 (PDT)
Received: from implode.root.com (implode.root.com [198.145.90.17])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA06980;
          Fri, 26 Sep 1997 07:25:38 -0700 (PDT)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.5/8.8.5) with ESMTP id HAA25055;
	Fri, 26 Sep 1997 07:26:28 -0700 (PDT)
Message-Id: <199709261426.HAA25055@implode.root.com>
To: Mike Smith <mike@smith.net.au>
cc: tarkhil@mgt.msk.ru, hackers@FreeBSD.ORG, stable@FreeBSD.ORG
Subject: Re: 'fxp' driver/hardware lossage (was Re: Alexander B. Povol's mail) 
In-reply-to: Your message of "Fri, 26 Sep 1997 18:43:16 +0930."
             <199709260913.SAA00775@word.smith.net.au> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Fri, 26 Sep 1997 07:26:27 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Putting the fxp driver into promiscuous mode involves poking at bits 
>of the interface hardware.  This appears to fix whatever it is that's 
>going wrong.  If this problem hasn't already been dealt with in the 
>-current/-stable drivers, I hope DG is looking at it.

   The card doesn't need to be put into promiscuous mode. Doing that has the
side effect of resetting the chip, which is all that is really needed. This
can be accomplished by doing a simple "ifconfig fxp0 up".
   There isn't anything wrong with the driver and working around the bug
in the hardware is difficult since there are no symptoms other than packets
not coming in anymore. The problem is well known and is covered in the
errata for the 82557 chip. Let me say again that this bug should only show
itself when there is something wrong on the network and usually only when
the card is in 10Mbps mode. I haven't seen a failure in the 9+ months that
I've used the Pro/100B in wcarchive, it's never happened here locally under
regular usage (I use these cards in about 5 machines), and in fact I've only
seen it occur myself when I've killed the power on my hub. Yahoo was having
this occur whenever the ISP power cycled the switch that the machines were
connected to, and I think they worked around it with some sort of
ping/ifconfig cron job.
   One of these days I'll conjure up some sort of hack to fix the problem.
Intel recommends reprogramming the multicast filter (!) if no packets are
received for some number of seconds. This is difficult to implement in the
current design of the driver.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project