From nobody@FreeBSD.org  Wed Feb  1 10:30:47 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7C06316A422
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  1 Feb 2006 10:30:47 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id BF2B743D72
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  1 Feb 2006 10:30:39 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k11AUdbE059495
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 1 Feb 2006 10:30:39 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k11AUcwS059493;
	Wed, 1 Feb 2006 10:30:39 GMT
	(envelope-from nobody)
Message-Id: <200602011030.k11AUcwS059493@www.freebsd.org>
Date: Wed, 1 Feb 2006 10:30:39 GMT
From: Dan Bilik <dan@mail.neosystem.cz>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure
X-Send-Pr-Version: www-2.3

>Number:         92675
>Category:       kern
>Synopsis:       [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 01 10:40:02 GMT 2006
>Closed-Date:    Mon Jul 12 22:10:48 UTC 2010
>Last-Modified:  Mon Jul 12 22:10:48 UTC 2010
>Originator:     Dan Bilik
>Release:        FreeBSD 6.0-STABLE
>Organization:
>Environment:
FreeBSD xxx.yyy.zz 6.0-STABLE FreeBSD 6.0-STABLE #0: Mon Jan  2 16:19:49 CET 2006

Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) III CPU family      1266MHz (1261.31-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b1  Stepping = 1
  Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 1073659904 (1023 MB)
avail memory = 1043476480 (995 MB)
MPTable: <IBM ENSW NF 4100R SMP>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  3
 cpu1 (AP): APIC ID:  0
ioapic0: Assuming intbase of 0
ioapic1: Assuming intbase of 16
ioapic1 <Version 1.1> irqs 16-31 on motherboard
ioapic0 <Version 1.1> irqs 0-15 on motherboard

fxp0: <Intel 82559 Pro/100 Ethernet> port 0x2200-0x223f mem 0xfeb7f000-0xfeb7ffff,0xfea00000-0xfeafffff irq 27 at device 2.0 on pci0
fxp0: Disabling dynamic standby mode in EEPROM
fxp0: New EEPROM ID: 0x48a0
fxp0: EEPROM checksum @ 0x3f: 0xaef7 -> 0xaef7
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:02:55:c6:e8:67

>Description:
Sometimes, mostly under heavy network load, receiver unit on the fxp(4) interface suffers an allocation failure and wedges. Affected machine then cannot receive any new packets, thus seems unreachable on the network. Turning off ACPI and/or using polling(4) on the interface doesn't solve the problem.
>How-To-Repeat:
Very hard to. From two identical boxes running the same tasks, one is wedging almost each day while the second one runs without a wedge for two weeks. I haven't figured out what exactly it depends on.

>Fix:
It can be unwedged by reinitializing the interface (for example by 'ifconfig promisc') or by generating software interrupt.
I have small patch that does this each tick and it completely resolved occasional wedges on our boxes that were previously hanging almost each day. It's available at http://neosystem.cz/freebsd/releng_6.if_fxp.rx_alloc_bug.patch.
>Release-Note:
>Audit-Trail:

From: "Andrew Pantyukhin" <infofarmer@FreeBSD.org>
To: bug-followup@FreeBSD.org, "Dan Bilik" <dan@mail.neosystem.cz>
Cc:  
Subject: Re: kern/92675: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure
Date: Thu, 22 Feb 2007 16:30:29 +0300

 Thanks a lot, Dan! Your patch works for me.
 
 I have the same chip in a dual-PIII i386
 box. I started experiencing the problem
 when the load got up to 4-5kpps (squid).
 Upgrading from 6.1 to 6.2 did not help,
 link0 had no effect. The adapter kept
 locking up once in a while, I had to use
 serial console to ifconfig it down and up.
 
 Now everything works fine, there's no
 obvious performance impact, either.
 
 Thanks!

From: "Andrew Pantyukhin" <infofarmer@FreeBSD.org>
To: bug-followup@freebsd.org, "Dan Bilik" <dan@mail.neosystem.cz>
Cc:  
Subject: Re: kern/92675: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure
Date: Wed, 21 Mar 2007 20:13:44 +0300

 On 2/22/07, Andrew Pantyukhin <infofarmer@freebsd.org> wrote:
 > Thanks a lot, Dan! Your patch works for me.
 >
 > I have the same chip in a dual-PIII i386
 > box. I started experiencing the problem
 > when the load got up to 4-5kpps (squid).
 > Upgrading from 6.1 to 6.2 did not help,
 > link0 had no effect. The adapter kept
 > locking up once in a while, I had to use
 > serial console to ifconfig it down and up.
 >
 > Now everything works fine, there's no
 > obvious performance impact, either.
 
 Today, after a month of 24/7 operation the
 card locked up again. ifconfig down-up helped,
 as usual.
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: vwe 
Responsible-Changed-When: Wed Jan 14 21:49:57 UTC 2009 
Responsible-Changed-Why:  

Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92675 
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Thu Jan 15 02:13:36 UTC 2009 
State-Changed-Why:  
fxp(4) in CURRENT has more robust code to cope with resource 
exhaustion. I think you can use fxp(4) in CURRENT without problems 
on 7.1-RELEASE or stable/7. Would you give it try? 
Also fxp(4) in HEAD supports Rx checksum offloading for 82559 so 
you may get slightly better performance. 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Thu Jan 15 02:13:36 UTC 2009 
Responsible-Changed-Why:  
Grab. 

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

From: Dan Bilik <dan@mail.neosystem.cz>
To: bug-followup@FreeBSD.org
Cc: yongari@FreeBSD.org, infofarmer@FreeBSD.org
Subject: Re: kern/92675: [fxp] [patch] fxp(4) unable to recover from
 occasional receiver unit allocation failure
Date: Thu, 15 Jan 2009 13:55:32 +0100

 On Thu, 15 Jan 2009 02:14:43 GMT
 yongari@FreeBSD.org wrote:
 
 > fxp(4) in CURRENT has more robust code to cope with resource
 > exhaustion. I think you can use fxp(4) in CURRENT without problems
 > on 7.1-RELEASE or stable/7. Would you give it try?
 
 Unfortunately the mentioned systems were retired from production some time
 ago. Currently I don't have resources to build similar test environment
 and reproduce the (quite high) traffic that was handled by the systems.
 
 I'm afraid I won't be able to give you any more feedback. As for me the case
 can be closed. But there was a response from Andrew - he may still be able
 to test.
State-Changed-From-To: feedback->open 
State-Changed-By: yongari 
State-Changed-When: Fri Jan 16 02:02:09 UTC 2009 
State-Changed-Why:  
Feedback received. Submitter has no more access to problematic system. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92675 
State-Changed-From-To: open->closed 
State-Changed-By: yongari 
State-Changed-When: Mon Jul 12 22:10:29 UTC 2010 
State-Changed-Why:  
Close. It is believed that all known issues for handling resource 
shortage condition were fixed. 

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