Re: e1000e driver, Intel 82567LF-2, link negotiation (and wol) problems

["David Härdeman" <david@hardeman.nu>]

On Thu, Jun 03, 2010 at 03:39:24PM -0700, John Ronciak wrote:
> On Thu, Jun 3, 2010 at 3:20 PM, David Härdeman <david@hardeman.nu> wrote:
> > I have an Intel DG45FC motherboard with an integrated gigabit NIC (lspci
> > says it's a "Intel Corporation 82567LF-2 Gigabit Network Connection").
> >
> > When using the in-kernel e1000e driver (tried up to kernel version
> > 2.6.34), the speed is negotiated to 100mbit (most of the time) even
> > though the NIC is connected to a gigabit switch using quality cables
> > (I've tried a few different to be sure).  There seems to be no real
> > pattern to when the link is negotiated to 100mbit or 1000mbit.
> >
> > I've tried Intel's version of the driver (e1000e from sourceforge,
> > version 1.1.19) and it seems to behave in the same way.
> >
> > The output from mii-tool is quite confusing:
> > scott:~# mii-tool -v eth0
> > SIOCGMIIREG on eth0 failed: Input/output error
> > SIOCGMIIREG on eth0 failed: Input/output error
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> >  product info: vendor 00:50:43, model 11 rev 0
> >  basic mode:   autonegotiation enabled
> >  basic status: autonegotiation complete, link ok
> >  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
> > 10baseT-HD
> >  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > flow-control
> >  link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
> > 10baseT-HD flow-control
> >
> > (capabilities and link partner agree on 1000mbit, but only 100mbit is
> > advertised according to mii-tool)
> >
> > ethtool disagrees with mii-tool:
> > scott:~# ethtool eth0
> > Settings for eth0:
> >        Supported ports: [ TP ]
> >        Supported link modes:   10baseT/Half 10baseT/Full 100baseT/Half
> > 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes
> >        Advertised link modes:  10baseT/Half 10baseT/Full 100baseT/Half
> > 100baseT/Full 1000baseT/Full Advertised pause frame use: No
> >        Advertised auto-negotiation: Yes
> >        Speed: 100Mb/s
> >        Duplex: Full
> >        Port: Twisted Pair
> >        PHYAD: 2
> >        Transceiver: internal
> >        Auto-negotiation: on
> >        MDI-X: on
> >        Supports Wake-on: pumbag
> >        Wake-on: g
> >        Current message level: 0x00000001 (1)
> >        Link detected: yes
> >
> > Manually setting the speed with ethtool doesn't work. Not sure how to
> > proceed...any suggestions?
> >
> > (And while I'm at it, the Intel e1000e driver from sourceforge seems to
> > have a wol init bug, ethtool reports "Wake-on: g" but I can wake a
> > suspended machine using a simple ping. Calling "ethtool -s eth0 wol g"
> > before suspending gets the expected behaviour - i.e. only wake on a
> > magic wol packet. Don't want to register on sourceforge just to report
> > that to the bug tracker though).
> >
> > Not subscribed to netdev, please CC me on any answers.
> >
> > --
> > David Härdeman
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> What is your link partner?  

A netgear gigabit switch

> Do different ones all do the same thing?

Haven't tried different ones yet, would have to lug hardware all over 
the apartment to do so

> Is the link partner configured for auto-neg?  

I guess so, switches should be?

> If you force speed and
> duplex to 1000/full on both sides, is it linked at 1000/full? 

Can't force anything on the switch 


> You have to force both sides of the connection for it to work 
> correctly.
> Same for auto-neg, both sides need to be set to do that.  Maybe the
> link partner is only advertising 100Mb and so that is what it is
> linking to?

The switch *is* advertising 1000Mb, if I reboot the computer *or* 
plug/unplug the cable, the NIC will negotiate 1000Mb about 1/3 of the 
time. Also, the NIC seems to negotiate 1000Mb while the computer is 
booting (during the BIOS phase, before the kernel takes over).

> -- 
> Cheers,
> John

Thanks for the feedback, any other suggestions? 

-- 
David Härdeman