kern/114839: [fxp] fxp looses ability to speak with traffic

[Pyun YongHyeon]

On Tue, Jun 23, 2009 at 01:00:10PM -0400, David Gilbert wrote:
> yongari at 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.
>