Date: Thu, 25 Aug 2011 17:39:18 -0500 From: Noel <noeldude@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Broadcom BCM5780 Link-UP before auto-negotiation completes Message-ID: <4E56CF16.4060703@gmail.com> In-Reply-To: <03f101cc636d$b01bd1a0$105374e0$@fisglobal.com> References: <03f101cc636d$b01bd1a0$105374e0$@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/25/2011 4:26 PM, Devin Teske wrote: > Hi All, > > I've got three different workstations each with a Broadcom Gigabit Ethernet card > (slightly different models, but all running the bge(4) device driver) on > FreeBSD-8.1 RELEASE. > > We've having a strange problem where each/every single reboot ends up in > dropping to single-user mode because the NFS mounts fail in-turn because the > bge0 interface claims to be up but hasn't completed auto-negotation of the > link-speed yet (and states "no carrier"). > > After being dropped to single-user mode, you can press ENTER to accept the > default shell of /bin/sh and then type ^D to exit -- machine continues booting > just fine. > > I've tried back-porting the recent changes from bge(4) in the > RELENG_8_2_0_RELEASE branch and even the RELENG_8 branch to no avail. > > I was really disappointed because I could have sworn that one of these two SVN > revs (both published for RELENG_8_2_0_RELEASE) would have fixed the problem: > > http://svnweb.freebsd.org/base?view=revision&revision=213808 > Add more checks for resolved link speed in bge_miibus_statchg(). > Link UP state could be reported first before actual completion of > auto-negotiation. This change makes bge(4) reprogram BGE_MAC_MODE, > BGE_TX_MODE and BGE_RX_MODE register only after controller got a > valid link. > > http://svnweb.freebsd.org/base?view=revision&revision=213711 > The IFF_DRV_RUNNING flag is set at the end of bge_init_locked. But > before setting the flag, interrupt was already enabled such that > interrupt handler could be run before setting IFF_DRV_RUNNING flag. > This can lose initial link state change interrupt which in turn > make bge(4) think that it still does not have valid link. Fix this > race by protecting the taskqueue with a driver lock. > While I'm here move reenabling interrupt code after handling of link > state change. > > I'm afraid that our next recourse is going to be (in order of preference): > > 1. Try back-porting from an even further target (HEAD -> RELENG_8_1_0_RELEASE; > RELENG_8 wasn't high enough and bug still occurred). > 2. Try firmware upgrade of the Broadcom controller > 3. Write a custom rc.d script to detect when bge(4) is in use and sleep for a > few seconds before proceeding to NFS mounts > > And if none of those work... > > 4. Unceremoniously rip bge(4) from our kernels to prevent usage in production -- > requiring the installation of a PCI or PCI-e or PCI-X network card that doesn't > suffer this issue. > > Suggestions welcome. I've found this workaround useful with my bge cards: http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html -- Noel Jones
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E56CF16.4060703>