re driver trobles (RELENG_5)
Oleg Bulyzhin
oleg at rinet.ru
Tue Mar 22 13:58:23 PST 2005
On Fri, 11 Mar 2005, Oleg Bulyzhin wrote:
> On Thu, 10 Mar 2005, Dmitry Morozovsky wrote:
>
>> Dear colleagues,
>>
>> experimenting with new amd64-based router we found strange re(4) behaviour
>> when working in autoselect media mode:
>>
>> whenever promisc mode turned on, renegotiating occurs, leading to 3 to 45
>> (depending on STP settings on the switch) network unavailability.
>>
>> Moreover, some other re(4) setting changes seem to disturb link state
>> unneededly (such as ifconfig re0 -vlanhwtag)
>>
>> The most annoying fact is that we non-autonegotiating mode with our re and
>> D-Link gigabit switches: fixing media at 1000BaseTX leads to link down
>> regardless of master/slave settings on both sides; on re side it is even
>> undocumented.
>>
>> Any clues?
>>
>> Thanks in advance.
>>
>> Sincerely,
>> D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
>> ------------------------------------------------------------------------
>> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
>> ------------------------------------------------------------------------
>
> Further investigation revealed even more weirdness of re driver:
>
> If re card plugged into switch (tested with Catalyst 2948G) with fixed port
> speed/duplex (100/full) settings, and we trying to reboot - re driver fails
> to
> attach:
>
> re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0xd000-0xd0ff mem
> 0xcfffbf00-0xcfffbfff irq 16 at device 11.0 on pci0
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S media interface> on miibus0
> rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
> 1000baseTX-FDX, auto
> re0: bpf attached
> re0: Ethernet address: 00:11:09:cd:15:77
> re0: diagnostic failed, failed to receive packet in loopback mode
> re0: attach aborted due to hardware diag failure
> rgephy0: detached
> miibus0: detached
> device_attach: re0 attach returned 5
>
> If switch port configured for 'auto' mode we can reboot without problems.
>
JFYI: attached patch solved both issues.
(made using http://people.freebsd.org/~wpaul/re/)
--
Oleg.
================================================================
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at rinet.ru ===
================================================================
-------------- next part --------------
--- sys/dev/mii/rgephy.c~ Sun Jan 30 03:59:54 2005
+++ sys/dev/mii/rgephy.c Thu Mar 17 10:43:58 2005
@@ -200,17 +200,13 @@
if ((mii->mii_ifp->if_flags & IFF_UP) == 0)
break;
- rgephy_reset(sc); /* XXX hardware bug work-around */
-
switch (IFM_SUBTYPE(ife->ifm_media)) {
case IFM_AUTO:
-#ifdef foo
/*
* If we're already in auto mode, just return.
*/
if (PHY_READ(sc, RGEPHY_MII_BMCR) & RGEPHY_BMCR_AUTOEN)
return (0);
-#endif
(void) rgephy_mii_phy_auto(sc);
break;
case IFM_1000_T:
@@ -341,6 +337,12 @@
bmsr = PHY_READ(sc, RGEPHY_MII_BMSR);
bmcr = PHY_READ(sc, RGEPHY_MII_BMCR);
+
+ if (bmcr & RGEPHY_BMCR_ISO) {
+ mii->mii_media_active |= IFM_NONE;
+ mii->mii_media_status = 0;
+ return;
+ }
if (bmcr & RGEPHY_BMCR_LOOP)
mii->mii_media_active |= IFM_LOOP;
--- sys/dev/re/if_re.c~ Sun Jan 30 04:00:00 2005
+++ sys/dev/re/if_re.c Thu Mar 17 02:19:37 2005
@@ -1059,7 +1059,7 @@
struct ifnet *ifp;
struct rl_hwrev *hw_rev;
int hwrev;
- u_int16_t re_did = 0;
+ u_int16_t re_did = 0, phy, bmsr;
int unit, error = 0, rid, i;
sc = device_get_softc(dev);
@@ -1212,6 +1212,22 @@
* Call MI attach routine.
*/
ether_ifattach(ifp, eaddr);
+
+ for (phy = 0; phy < 32; phy++) {
+ bmsr = re_miibus_readreg(dev, phy, MII_BMSR);
+ bmsr = re_miibus_readreg(dev, phy, MII_BMSR);
+ if (!bmsr) continue;
+
+ re_miibus_writereg(dev, phy, MII_BMCR, BMCR_RESET);
+ for (i = 0; i < RL_TIMEOUT; i++) {
+ if (!(re_miibus_readreg(dev, phy, MII_BMCR) &
+ BMCR_RESET)) break;
+ DELAY(100);
+ }
+ re_miibus_writereg(dev, phy, MII_BMCR, BMCR_LOOP);
+
+ break;
+ }
/* Perform hardware diagnostic. */
error = re_diag(sc);
More information about the freebsd-stable
mailing list