From root@dev.eicat.ca  Mon Jul 23 21:14:32 2007
Return-Path: <root@dev.eicat.ca>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D7F9A16A417
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 23 Jul 2007 21:14:32 +0000 (UTC)
	(envelope-from root@dev.eicat.ca)
Received: from dev.eicat.ca (dev.eicat.ca [66.96.25.75])
	by mx1.freebsd.org (Postfix) with ESMTP id C88E113C459
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 23 Jul 2007 21:14:32 +0000 (UTC)
	(envelope-from root@dev.eicat.ca)
Received: by dev.eicat.ca (Postfix, from userid 0)
	id 73A8A1CE30; Mon, 23 Jul 2007 16:56:52 -0400 (EDT)
Message-Id: <20070723205652.73A8A1CE30@dev.eicat.ca>
Date: Mon, 23 Jul 2007 16:56:52 -0400 (EDT)
From: dave@daveg.ca
Reply-To: dave@daveg.ca
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: fxp looses ability to speak with traffic
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         114839
>Category:       kern
>Synopsis:       [fxp] fxp looses ability to speak with traffic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 23 21:20:01 GMT 2007
>Closed-Date:    Tue Jul 06 00:42:58 UTC 2010
>Last-Modified:  Tue Jul 06 00:42:58 UTC 2010
>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@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@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:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: remko 
Responsible-Changed-When: Wed Jul 25 06:03:17 UTC 2007 
Responsible-Changed-Why:  
This seems more appropriate for the networking list, reassign. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Tue Jun 23 08:27:34 UTC 2009 
State-Changed-Why:  
It seems your controller is plain i82559. Since you said you can 
see incoming traffics I think the controller do not have lock-up 
bug. By chance do you use fxp(4) on PAE environments or systems 
with more than 4GB of memory? Show me the output of 
"sysctl hw.busdma" to see whether bounce buffers are used. 

Also there was a lot of fxp(4) changes in HEAD. Could you try 
latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you 
can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD 
to 7-stable/7.2-RELEASE and rebuild kernel. 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Tue Jun 23 08:27:34 UTC 2009 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: David Gilbert <dave@daveg.ca>
Cc: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/114839: [fxp] fxp looses ability to speak with traffic
Date: Wed, 24 Jun 2009 10:19:58 +0900

 On Tue, Jun 23, 2009 at 01:00:10PM -0400, David Gilbert wrote:
 > yongari@FreeBSD.org wrote:
 > >Synopsis: [fxp] fxp looses ability to speak with traffic
 > >
 > >State-Changed-From-To: open->feedback
 > >State-Changed-By: yongari
 > >State-Changed-When: Tue Jun 23 08:27:34 UTC 2009
 > >State-Changed-Why: 
 > >It seems your controller is plain i82559. Since you said you can
 > >see incoming traffics I think the controller do not have lock-up
 > >bug. By chance do you use fxp(4) on PAE environments or systems
 > >with more than 4GB of memory? Show me the output of
 > >"sysctl hw.busdma" to see whether bounce buffers are used.
 > >
 > >Also there was a lot of fxp(4) changes in HEAD. Could you try
 > >latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you
 > >can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD
 > >to 7-stable/7.2-RELEASE and rebuild kernel.
 > >
 > >
 > >Responsible-Changed-From-To: freebsd-net->yongari
 > >Responsible-Changed-By: yongari
 > >Responsible-Changed-When: Tue Jun 23 08:27:34 UTC 2009
 > >Responsible-Changed-Why: 
 > >Grab.
 > >
 > >http://www.freebsd.org/cgi/query-pr.cgi?pr=114839
 > >  
 > Unfortunately, I lost access to that machine due to some business issues 
 > :).  But I can tell you that it didn't have PAE enabled nor did it have 
 > 4G of memory (it either had 1G or 2G, but definately not 4G).
 > 
 
 Ok, thanks for reply.
 
 > Congrats on the cleanup of old tickets, but I can't do any testing for 
 > you as I don't have any other machines that did this.  The server in 
 > question was a busy core router.  My current core routers use em and bge 
 
 The server was SMP box? Also you used to rely on DEVICE_POLLING on
 fxp(4)?
 
 It's hard to say what was wrong here. You didn't encounter watchdog
 timeouts and you saw incoming traffic so I guess the controller is
 alive. What makes me wonder is why other end can't see frames sent
 from fxp(4). Are you sure you could be able to see incoming
 traffic? 
 
 Checking netstat(1) also may have helped to analyze the issue as
 fxp(4) uses hardware MAC counters. ATM the only possible cause of
 the issue I can think of is the side-effect of disabling dynamic
 standby mode. You have to cold reboot(shutdown and remove power
 cord and wait a couple of min before replug the power cord) your
 box if you see the following message.
 fxp0: Disabling dynamic standby mode in EEPROM
 Otherwise you may encounter watchdog timeouts or odd behaviour.
 
 > chipsets.
 > 
State-Changed-From-To: feedback->closed 
State-Changed-By: yongari 
State-Changed-When: Tue Jul 6 00:42:37 UTC 2010 
State-Changed-Why:  
Feedback timeout(> 12 months). If you still see the issue on more 
recent FreeBSD releases, please open PR again. 
Thanks for reporting. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 
>Unformatted:
