Broadcom BCM5780 Link-UP before auto-negotiation completes
noeldude at gmail.com
Thu Aug 25 23:34:23 UTC 2011
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:
> 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.
> 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:
-- Noel Jones
More information about the freebsd-questions