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

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

[David Härdeman]

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

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

[John Ronciak]

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?  Do different ones all do the same thing?
Is the link partner configured for auto-neg?  If you force speed and
duplex to 1000/full on both sides, is it linked at 1000/full?  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?


-- 
Cheers,
John

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

[David Härdeman]

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