Date: Wed, 24 Jun 2009 10:19:58 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: David Gilbert <dave@daveg.ca> Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/114839: [fxp] fxp looses ability to speak with traffic Message-ID: <20090624011958.GE10712@michelle.cdnetworks.co.kr> In-Reply-To: <4A410A1A.3050403@daveg.ca> References: <200906230828.n5N8Sfi9048897@freefall.freebsd.org> <4A410A1A.3050403@daveg.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090624011958.GE10712>