Using NetBSD-current/amd64 on Sunfire X2200-M2 servers

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I'm trying to update some of our very old Sunfire X2200-M2 servers from NetBSD-5.2
to NetBSD-current/amd64.  These are the machines with ELOM/BMc modules on one of the Broadcom
ethernet ports which share the physical port with the host machine.  
the latest commit for NetBSD-5.2 fixed pr kern/49657, which also fixed an issue where when the
machine booted, it would knock the LOM board off the net.

	Unfortunately, this problem crops up again with NetBSD-9.x and nNetBSD-current sources.
I've been pouring over the 5.2 driver versus the -current driver to see if I can figure out
what the difference is that causes the problem.
What I've figured out is that it has something to do with the way the phy gets initialized.
Specifically, if the LOM negotiates 100 mbits/sec, full duplex with the switch, when NetBSD
boots, it leaves the  media set to 10 mbits/sec full-duplex.  It's possible to fix the issue
manually, by performing an ifconfig up on the interface.  That forces the media to reset to the
correct value for the NetBSD host and the LOM.  Running ifconfig down on the interface after
running the initial "up" command doesn't cause the corrected value to go away.  That is to say,
once one brings the connection "up", it will stay up regardless of the current running state of
the interface from NetBSD's perspective.  The 5.2 code doesn't do this; it seems to be able to
leave the pre-negotiated media value alone.  One difference I notice between the two drivers is
that the older one uses the MIIF_ANEG flag when it initializes the phy media.  So, I tried
doing that on the new driver, with no change.

	Has anyone else run into this with the bge(4) driver and, if so, what fixes or ideas did
you come up with to correct the issue?

I realize I could work around this with user-land code, but that doesn't solve the problem that
if I need to bring the system up in single user mode, I can't do it using the LOM console
remotely.  that's a real problem for me, since I'm miles away from these machines.

Any ideas would be greatly appreciated.

-thanks
-Brian