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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
