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
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
Reported here also: http://bugzilla.kernel.org/show_bug.cgi?id=10990
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.
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
updated bugzilla.kernel.org with instructions to turn off iAMT on this HP system.
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
Fixed in 2.6.26.5-35
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
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
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
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
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.