Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453023 - e1000/e1000e driver doesn't work with gigabit connection
Summary: e1000/e1000e driver doesn't work with gigabit connection
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Andy Gospodarek
QA Contact: Fedora Extras Quality Assurance
URL: http://bugzilla.kernel.org/show_bug.c...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-26 18:38 UTC by Michael J. Chudobiak
Modified: 2014-06-29 23:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-01 06:37:24 UTC


Attachments (Terms of Use)
patch to fix iAMT interaction (deleted)
2008-09-11 17:48 UTC, Jesse Brandeburg
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Linux Kernel 10990 None None None Never

Description Michael J. Chudobiak 2008-06-26 18:38:58 UTC
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 18:44:37 UTC
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 19:21:58 UTC
Reported here also:

http://bugzilla.kernel.org/show_bug.cgi?id=10990

Comment 3 Jesse Brandeburg 2008-07-11 20:04:52 UTC
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 11:32:03 UTC
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 21:45:42 UTC
updated bugzilla.kernel.org with instructions to turn off iAMT on this HP system.


Comment 6 Jesse Brandeburg 2008-09-11 17:48:25 UTC
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 07:23:23 UTC
Fixed in 2.6.26.5-35

Comment 8 Fedora Update System 2008-09-14 06:14:16 UTC
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 23:21:19 UTC
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 06:29:51 UTC
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-25 00:17:01 UTC
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 06:36:54 UTC
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.