RTL8102E (if_re) doesn't work with -current

[Pyun YongHyeon]

On Wed, Dec 17, 2008 at 05:46:33PM +0900, To Bruce Cran wrote:
 > On Tue, Dec 16, 2008 at 10:10:19PM -0800, Bruce Cran wrote:
 >  > Pyun YongHyeon 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.
 >  > >  
 >  > The laptop is connected straight into the apartment internet system, so 
 >  > I don't know what sort of switch it is.  However I applied your 2nd 
 >  > patch but nothing changed; the ifconfig output is still
 >  > 
 >  > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 >  >    
 >  > options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
 >  >    ether 00:1e:ec:f5:fd:4f
 >  >    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
 >  >    media: Ethernet autoselect (100baseTX <full-duplex>)
 >  >    status: active
 >  > 
 >  > I did notice that if I unplug and replug the UTP cable while dhclient is 
 >  > trying to find a lease during startup then as soon as I plug it in again 
 >  > it claims to find a lease and configures the IP address, routes etc.  
 >  > However trying to ping anything once the system has started results in 
 >  > the message "No buffer space available" so the network isn't really working.
 >  > 
 > 
 > Would you try attached patch again?(Don't backout rlphy.patch2).

Oops, please forget previous patch and use attached patch instead.

-- 
Regards,
Pyun YongHyeon
-------------- next part --------------
Index: if_re.c
===================================================================
--- if_re.c	(revision 186214)
+++ if_re.c	(working copy)
@@ -2681,7 +2681,14 @@
 	ifp->if_drv_flags |= IFF_DRV_RUNNING;
 	ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
 
-	sc->rl_flags &= ~RL_FLAG_LINK;
+	/*
+	 * XXX
+	 * Since we don't request reset for rlphy(4), it's necessary
+	 * to set initial (fake) link state. Otherwise re(4) wouldn't
+	 * work as link state 'UP' event from mii(4) may not be
+	 * delivered if the valid link was already established.
+	 */
+	sc->rl_flags |= RL_FLAG_LINK;
 	sc->rl_watchdog_timer = 0;
 	callout_reset(&sc->rl_stat_callout, hz, re_tick, sc);
 }