RTL8102E (if_re) doesn't work with -current
Pyun YongHyeon
pyunyh at gmail.com
Wed Dec 17 04:28:45 UTC 2008
On Wed, Dec 17, 2008 at 12:41:55PM +0900, To Bruce Cran wrote:
> 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.
Please try this one, there was a typo in previous 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;
- }
+ } else 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