Bug 453023 - e1000/e1000e driver doesn't work with gigabit connection
e1000/e1000e driver doesn't work with gigabit connection
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Andy Gospodarek
Fedora Extras Quality Assurance
http://bugzilla.kernel.org/show_bug.c...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-26 14:38 EDT by Michael J. Chudobiak
Modified: 2014-06-29 19:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-01 02:37:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix iAMT interaction (3.50 KB, patch)
2008-09-11 13:48 EDT, Jesse Brandeburg
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 10990 None None None Never

  None (edit)
Description Michael J. Chudobiak 2008-06-26 14:38:58 EDT
Linux lyra 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun 10 16:27:49 EDT 2008 i686 i686
i386 GNU/Linux

I have a multiple HP DC7700s with integrated Intel ethernet adapters. They work
when the network cable is plugged into a 10/100 port on a switch. They do not
work when plugged into a 10/100/1000 port. I also have DC7700s with integrated
Broadcom chips (tg3 driver) and they work fine.

From dmesg:
e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0
e1000e: Copyright (c) 1999-2007 Intel Corporation.
...
eth0: (PCI Express:2.5GB/s:Width x1) 00:0f:fe:4a:68:37
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 4, PHY: 6, PBA No: 1002ff-0ff

When plugged into a 10/100/1000 porting, forcing:
ethtool -s eth0 autoneg off speed 1000 duplex full

results in erratic (some pings work) or dead operation (no pings work).

Using:
ethtool -s eth0 autoneg off speed 100 duplex full

seems to work OK.

Returning it to autoneg results in erratic/dead operation:

[root@lyra ~]# ethtool -s eth0 autoneg on
[root@lyra ~]# 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 auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbag
	Wake-on: g
	Current message level: 0x00000001 (1)
	Link detected: yes
[root@lyra ~]# ping server2
PING server2.domain.avtechpulse.com (192.168.0.3) 56(84) bytes of data.
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=1 ttl=64
time=0.079 ms
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=2 ttl=64
time=0.158 ms
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=7 ttl=64
time=0.161 ms
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=11 ttl=64
time=0.113 ms
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=12 ttl=64
time=0.131 ms
64 bytes from server2.domain.avtechpulse.com (192.168.0.3): icmp_seq=17 ttl=64
time=0.127 ms
^C
--- server2.domain.avtechpulse.com ping statistics ---
18 packets transmitted, 6 received, 66% packet loss, time 17553ms
rtt min/avg/max/mdev = 0.079/0.128/0.161/0.028 ms
[root@lyra ~]# 

This was confirmed with multiple 10/100/1000 switches from different manufacturers.

Need any additional data?

- Mike
Comment 1 Michael J. Chudobiak 2008-06-26 14:44:37 EDT
Forgot to add:

[root@lyra ~]# more /etc/modprobe.conf
alias eth0 e1000e  #same behaviour with "e1000"
alias scsi_hostadapter libata
alias scsi_hostadapter1 ata_piix
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0


Comment 2 Michael J. Chudobiak 2008-06-26 15:21:58 EDT
Reported here also:

http://bugzilla.kernel.org/show_bug.cgi?id=10990
Comment 3 Jesse Brandeburg 2008-07-11 16:04:52 EDT
hm, what happens when you just load the driver while plugged into the gigabit
switch?  No ethtool commands should be necessary to get link at 1Gb.

Also, please check your BIOS to see if you have the ME(management engine) or
IAMT enabled.   Please make sure you have the latest BIOS available.

What does ethtool -S say after losing some pings, are you able to get link back
to back with another 7700?  do pings work then?

There is a patch having to do with the DRV_LOAD bit that we have pushed upstream
that may not have made it into current production kernels.
Comment 4 Michael J. Chudobiak 2008-07-12 07:32:03 EDT
Jesse,

If the DC7700 is plugged into a gigabit switch in the normal manner (without
ethtool), a gigabit connection is established (as you would expect). However,
pings are erratic, nfs is unusable.

Forcing 100 Mb/s operation with ethtool results in reliable operation.

I am using two workarounds, currently. On some computers, I've connected them to
100 Mb switches instead of gigabit switches. On others, I installed Intel PCI
gigabit adapters (as eth1) and disabled the embedded eth0. Those arrangements
work fine.

I posted some additional details in the upstream kernel bugzilla.

BIOS updates did not fix anything.

Regarding management engines: I don't think these computers have IAMT or ME.

I will be on vacation, away from these computers, next week.

- Mike
Comment 5 Jesse Brandeburg 2008-07-16 17:45:42 EDT
updated bugzilla.kernel.org with instructions to turn off iAMT on this HP system.
Comment 6 Jesse Brandeburg 2008-09-11 13:48:25 EDT
Created attachment 316465 [details]
patch to fix iAMT interaction

patch is pushed upstream to fix this, commit c43bc57e5d72932b5e64bc5e4e7741bedbcaaf5f

I've had some confirmation that a user that was seeing this exact issue had the problem resolved by applying this patch.

I believe this patch needs to be applied to e1000e in F9
Comment 7 Chuck Ebbert 2008-09-13 03:23:23 EDT
Fixed in 2.6.26.5-35
Comment 8 Fedora Update System 2008-09-14 02:14:16 EDT
kernel-2.6.26.5-39.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kernel-2.6.26.5-39.fc9
Comment 9 Fedora Update System 2008-09-16 19:21:19 EDT
kernel-2.6.26.5-39.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8089
Comment 10 Fedora Update System 2008-09-20 02:29:51 EDT
kernel-2.6.26.5-44.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kernel-2.6.26.5-44.fc9
Comment 11 Fedora Update System 2008-09-24 20:17:01 EDT
kernel-2.6.26.5-45.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8283
Comment 12 Fedora Update System 2008-10-01 02:36:54 EDT
kernel-2.6.26.5-45.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.