RTL8102E (if_re) doesn't work with -current

Pyun YongHyeon pyunyh at gmail.com
Wed Dec 17 03:42:03 UTC 2008


On Tue, Dec 16, 2008 at 07:15:41PM -0800, Bruce Cran wrote:
 > Pyun YongHyeon wrote:
 > >On Tue, Dec 16, 2008 at 09:30:02AM -0800, Bruce Cran wrote:
 > > > I just upgraded an HP Pavillion laptop from 7.1-RC1 to 8-CURRENT last 
 > > > night and now the network doesn't work.  This laptop has a RTL8102E 
 > > > chip, and no errors appear in the logs - it attaches and doesn't claim 
 > > > to have any TX/RX errors, but it just doesn't do anything.  I've 
 > > > attached the dmesg from a verbose boot.   I've seen messages saying 
 > > > there might be issues with MSI interrupts - is that possibly an issue 
 > > here?
 > > > 
 > >
 > >No, it is in disabled state by default.
 > >The issue could be related with link state tracking code in re(4).
 > >Would you show me the output of "devinfo -rv | grep rlphy"?
 > >How about unplugging/replugging UTP cable?
 > >Does it make any difference?
 > >  
 > 
 > devinfo provides the output:
 >                rlphy0 pnpinfo oui=0x20 model=0x20 rev=0x1 at phyno=1
 > 
 > I let the startup continue so that dhclient was still running in the 
 > background, and I started getting lots of messages:
 > 
 > arp: 00:1e:ec:72:2b:8e attempts to modify permanent entry for 0.0.0.0 on re0
 > 
 > After unplugging the replugging the UTP cable the messages
 > 
 > re0: link state changed to DOWN
 > re0: link state changed to UP
 > 
 > apppeared in the logs but dhclient still didn't get any replies, and the 
 > arp messages started again.
 > 

Hmm, this seem to happen when link partner doesn't support NWAY
autonegotiation. Can you confirm that?
And would you try attached patch? Also show me the outout of
"ifconfig re0" before/after applying attached patch.

-- 
Regards,
Pyun YongHyeon
-------------- next part --------------
Index: sys/dev/mii/rlphy.c
===================================================================
--- sys/dev/mii/rlphy.c	(revision 186170)
+++ sys/dev/mii/rlphy.c	(working copy)
@@ -60,6 +60,9 @@
 struct rlphy_softc {
 	struct mii_softc sc_mii;	/* generic PHY */
 	int sc_is_RTL8201L;		/* is an external RTL8201L PHY */
+	int flags;
+#define	RLPHY_FLAGS_RL		0x01
+#define	RLPHY_FLAGS_RE		0x02
 };
 
 static int rlphy_probe(device_t);
@@ -125,6 +128,7 @@
 	struct mii_attach_args	*ma;
 	struct mii_data		*mii;
 	struct rlphy_softc 	*rsc;
+	const char		*nic;
 
 	sc = device_get_softc(dev);
 	ma = device_get_ivars(dev);
@@ -138,6 +142,11 @@
 	rsc = (struct rlphy_softc *)sc;
 	if (mii_phy_dev_probe(dev, rlphys, 0) == 0)
 		rsc->sc_is_RTL8201L++;
+	nic = device_get_name(device_get_parent(sc->mii_dev));
+	if (strcmp(nic, "re") == 0)
+		rsc->flags |= RLPHY_FLAGS_RE;
+	else if (strcmp(nic, "rl") == 0)
+		rsc->flags |= RLPHY_FLAGS_RL;
 	
 	/*
 	 * The RealTek PHY can never be isolated, so never allow non-zero
@@ -302,18 +311,25 @@
 		 *   can test the 'SPEED10' bit of the MAC's media status
 		 *   register.
 		 */
-		if (rsc->sc_is_RTL8201L) {
-			if (PHY_READ(phy, 0x0019) & 0x01)
+		if (rsc->flags & RLPHY_FLAGS_RE) {
+			if (PHY_READ(phy, RL_GMEDIASTAT) &
+			    RL_GMEDIASTAT_100MBPS)
 				mii->mii_media_active |= IFM_100_TX;
 			else
 				mii->mii_media_active |= IFM_10_T;
-		} else {
+		} else if (rsc->flags & RLPHY_FLAGS_RL) {
 			if (PHY_READ(phy, RL_MEDIASTAT) &
 			    RL_MEDIASTAT_SPEED10)
 				mii->mii_media_active |= IFM_10_T;
 			else
 				mii->mii_media_active |= IFM_100_TX;
-		}
+		} if (rsc->sc_is_RTL8201L) {
+			if (PHY_READ(phy, 0x0019) & 0x01)
+				mii->mii_media_active |= IFM_100_TX;
+			else
+				mii->mii_media_active |= IFM_10_T;
+		} else
+			mii->mii_media_active |= IFM_NONE;
 	} else
 		mii->mii_media_active = ife->ifm_media;
 }


More information about the freebsd-current mailing list