kern/114839: fxp looses ability to speak with traffic

[dave at daveg.ca]

>Number:         114839
>Category:       kern
>Synopsis:       fxp looses ability to speak with traffic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 23 21:20:01 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     David Gilbert
>Release:        FreeBSD 6.2-RELEASE-p5 i386
>Organization:
DaveG.ca
>Environment:
System: FreeBSD dev.eicat.ca 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #2: Sun Jul 8 00:44:06 EDT 2007 root at dev.eicat.ca:/usr/obj/usr/src/sys/DEV i386


There seems to be a lot of FXP's out there and I don't believe I'm
seeing this on all of them, so this fxp is specifically:

dmesg says:

fxp0: <Intel 82559 Pro/100 Ethernet> port 0xe400-0xe43f mem 0xed203000-0xed203fff,0xed100000-0xed1fffff irq 19 at device 8.0 on pci0
miibus1: <MII bus> on fxp0
fxp0: Ethernet address: 00:d0:b7:9d:0f:f7

and pciconf -lv says:

fxp0 at pci0:8:0:  class=0x020000 card=0x000e8086 chip=0x12298086 rev=0x08 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
    class    = network
    subclass = ethernet

>Description:
When this bug happens, all communication from the fxp stops.  It appears
to still see packets coming in --- other machines arp addresses remain
current, but it doesn't send packets out.  I tried hardcoding the
mac address of the router --- thinking it was a mac issue, but this
also did not help.

I also tried putting an address on the raw port (the machine talks
on two vlans, otherwise) and the raw port stops talking just as
the vlans stop talking.
>How-To-Repeat:
In my case, this is totally repeatable (in minutes, no less).  20 megabit
of bit torrent traffic in either direction or 10 megabit in each direction
seems to cause it repeatably.  More traffic seems to cause it sooner.

It seems to only happen to certain fxp's.  I've had it happen in the past
... but the card listed above is my only current example.
>Fix:

Curiously, the only workaround I have is to have serial port connected to
another machine and to login and run "ifconfig fxp0 down ; ifconfig fxp0 up"
... which is rather inconvenient.  The other workaround is to run
bit torrent with limits.



>Release-Note:
>Audit-Trail:
>Unformatted: