Thank you Brad <[email protected]>, for supplying me with this patch,
which solves the problem (by adding the BCM57780 properly, and
having it use brgphy instead of ukphy). And thanks for the amazingly
fast support!
Index: miidevs
===================================================================
RCS file: /cvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.111
diff -u -p -r1.111 miidevs
--- miidevs 7 Sep 2009 13:46:03 -0000 1.111
+++ miidevs 15 Feb 2010 23:19:43 -0000
@@ -93,6 +93,7 @@ oui xxLEVEL1 0x1e0400 Level 1
/* Don't know what's going on here. */
oui xxBROADCOM2 0x0050ef Broadcom
+oui xxBROADCOM3 0x00d897 Broadcom
oui xxDAVICOM 0x006040 Davicom
/* This is the OUI of the gigE PHY in the RealTek 8169S/8110S chips */
@@ -152,6 +153,7 @@ model xxBROADCOM2 BCM5722 0x002d BCM5722
model xxBROADCOM2 BCM5784 0x003a BCM5784 10/100/1000baseT PHY
model xxBROADCOM2 BCM5709C 0x003c BCM5709 10/100/1000baseT PHY
model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY
+model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY
model BROADCOM BCM5400 0x0004 BCM5400 1000baseT PHY
model BROADCOM BCM5401 0x0005 BCM5401 1000baseT PHY
model BROADCOM BCM5411 0x0007 BCM5411 1000baseT PHY
Index: brgphy.c
===================================================================
RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.89
diff -u -p -r1.89 brgphy.c
--- brgphy.c 8 Aug 2009 19:07:03 -0000 1.89
+++ brgphy.c 15 Feb 2010 23:20:36 -0000
@@ -163,6 +163,8 @@ static const struct mii_phydesc brgphys[
MII_STR_xxBROADCOM2_BCM5709C },
{ MII_OUI_xxBROADCOM2, MII_MODEL_xxBROADCOM2_BCM5709CAX,
MII_STR_xxBROADCOM2_BCM5709CAX },
+ { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
+ MII_STR_xxBROADCOM3_BCM57780 },
{ MII_OUI_BROADCOM2, MII_MODEL_BROADCOM2_BCM5906,
MII_STR_BROADCOM2_BCM5906 },
On Mon, Feb 15, 2010 at 03:38:24PM -0500, Kenneth R Westerback wrote:
> On Sun, Feb 14, 2010 at 08:36:56PM -0800, bruce wrote:
> > I've been trying to get OpenBSD working with a new Dell Inspiron
> > Zino, and I've run into what I think may be a bug in mii_physubr.c.
> >
> > First, the symptoms:
> >
> > (1) /bsd.rd works just fine. I can use the BCM57780 GigE
> > network card as bge0 and reach the network. OpenBSD installs
> > correctly.
> >
> > (2) /bsd panics during bootup. The last lines on console read:
> > Starting network
> > panic: mii_phy_setmedia
> > (and then a warning about reporting errors)
> >
> > This is with the 4.6 CD set, but I get the same behavior with the
> > latest snapshot. Looking at the source code to mii_physubr.c, I
> > see that the panic occurs here at line 96:
> >
> > #ifdef DIAGNOSTIC
> > if (ife->ifm_data < 0 || ife->ifm_data >= MII_NMEDIA)
> > panic("mii_phy_setmedia");
> > #endif
> >
> > It turns out that in bsd.rd, DIAGNOSTIC is not defined, so
> > the section is skipped and everything works. In bsd,
> > the value ife->ifm_data is MII_NMEDIA. After a little
> > more poking around, I found that ife->ifm_data is set to
> > MII_NMEDIA at line 461 of mii_physubr.c:
> >
> > if (sc->mii_capabilities & BMSR_ANEG) {
> > ADD(IFM_MAKEWORD(IFM_ETHER, IFM_AUTO, 0, sc->mii_inst),
> > MII_NMEDIA); /* intentionally invalid index */
> > }
> >
> > I've put a bunch of printf's in both places, and I know
> > for sure that that section of code, for the BCM57780
> > using the bge driver and ukphy, will have BMSR_ANEG set
> > in mii_capabilities and will fail in this way.
> > BMSR_ANEG is defined in mii.h:
> >
> > define BMSR_ANEG 0x0008 /* Autonegotiation capable */
> >
> > Does this mean that if the network device supports Autonegotiation,
> > then kernel panic? I can't possibly be reading this right.
>
> Sounds like it is expecting the autonegotiation process to set
> ife->ifm_data to the correct value. But the autonegotiation is
> failing, incomplete or not being done.
>
> .... Ken
>
> >
> > If I comment out the panic, then everything works fine: the OS
> > boots, the bge0 device works properly, I can reach the network,
> > everything is hunky dory. The system is at least stable
> > enough for me to be writing this email. But, I'm now running
> > my own hacked kernel, which is a little more bleeding edge
> > than I'm used to. So, what's the real bug here?
> >
> > Thanks,
> > -Bruce
