Red Hat Bugzilla – Bug 250591
2.6.22 kernels e1000 gigabit networking started as 10/100
Last modified: 2007-11-30 17:12:12 EST
Description of problem: On my new ASUS P5B-VM DO (Vpro)motherboard based machine
the latest 2.6.22 series kernels start the network in gigabit mode but it fall
back to 10/100 mode later in the boot process
Re-installed the original F7 i686 kernel and all is OK
Version-Release number of selected component (if applicable):
Kernel 126.96.36.199-33 and later.
Always with both 188.8.131.52-33 and 44
Steps to Reproduce:
1.boot into 2.6.22 series kernel
Network initialised in 10/100 mode instead of gigabit mode
Network started in gigabit mode
Additional info:dmesg from current boot (184.108.40.206-33) attached.
Created attachment 160513 [details]
dmesg ouput of current boot to 220.127.116.11-33 kernel
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000: 0000:00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:1a:92:19:92:e5
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control:
e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO
It never says anything about starting out at 1000 then dropping to 100.
Please post messages from the working kernel.
Created attachment 160700 [details]
dmesg output from a working kernel.
dmesg ouput from the re-installed working kernel as requested.
I agree but wacthing the network switch the machine is attached to the speed
changes from 100 to 1000 and back to 100 during the boot process in the time
after udev is shown on the text screen just before x is stated to display the
graphical boot screen.
Exactly which model of e1000 is this?
Please post output of 'lspci' and also 'lspci -n'.
Created attachment 160768 [details]
lspci as requested
Created attachment 160769 [details]
lspci -n as requested
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network
Connection (rev 02)
00:19.0 0200: 8086:104a (rev 02)
Could this be caused by our ich9 support patch?
I see some places where we changed behavior for ich8, like:
@@ -1138,7 +1155,9 @@ e1000_probe(struct pci_dev *pdev,
* DRV_LOAD until the interface is up. For all other cases,
* let the f/w know that the h/w is now under the control
* of the driver. */
- if (adapter->hw.mac_type != e1000_82573 ||
+ if (((adapter->hw.mac_type != e1000_82573) &&
+ (adapter->hw.mac_type != e1000_ich8lan) &&
+ (adapter->hw.mac_type != e1000_ich9lan)) ||
What happens if you use ethtool to restart autonegotiation after you bring the
adapter up? Also, have you tried this with an alternate switch?
I do not have another switch to try but all works as expected in F7 with the
ethtool -r eth0 causes the expected re-negotiation the switch shows a change to
1000 but then reverts to 10/100.
I also have F8 test1 on the machine now and this with the original kernel also
ens up in 10/100 mode exhibiting the same behavior on boot that the 2.6.22
kernels do in F7
If I do a service network stop then start in quick succession with the interface
in 10/100 mode to start with as a result of the stop a re-negotiation to 1000
mode takes place then drops back to 10/100 (as seen by the switch) and if you
start the network again while the switch is showing the interface in 1000 mode
the network start ok and stays in 1000 mode but if you wait till the switch
shows 10/100 it starts in 10/100 mode.
The above if true for both F7 (2.6.22) and F8 test1
ethtool -s eth0 speed 1000 while in 10/100 mode the switch shows it transition
to 1000 then return to 10/100 and if in 1000 mode the link is droped comes back
in 1000 mode then is droped again and ends up in 10/100 mode.
NB As of tomorrow the 11th I will be away on holiday for a week and not have
access to my machine at home if any further info is required.
I will check this bug report reugularily today till 22:00 BST (GMT+1)
well, thats odd. Chuck may be right, the ich8 support may have borked something
but its a bit hard to tell. Can you pass debug=16 as a module option when you
load e1000, that should give us some indicator as to whats going on during
Can you please give a quick explanation of how I do that.
in /etc/modprobe.conf, append:
options e1000 debug=16
Then bring down the interface, remove the module, and bring it back up (or just
reboot the box).
Done that but wher is the debug output that you need to see.
Created attachment 161068 [details]
messages.tx of latest boot into initial F8test1 kernel
Since the problem is also evident in F8test1 and this has a kernel that will be
updated rapidly output from F8test1 given.
Consider changing it devel from F7
Status changed to ON_DEV
Well, it looks like you're going down the same code path in both cases, its just
that in the later kernels we goto look at what the phy negotiated to, and the
hardware reports 100/full instead of 1000 so thats what the driver logs. We
dont do much phy setup when we open the device, so I'm not quite sure whats
going on. Nothing in the upstream logs shows much interesting in the last few
months, save for some firmware mangement bits. Does your adapter support IPMI?
If so, can you go disable it in the bios and see if that corrects your problem?
otherwise we'll likely have to start a bisect to see where this problem started.
I have the same problem on a bunch of HP dc7700 machines using the e1000 module and kernel
18.104.22.168-33.fc7. After upgrading to gigabit switches, I first noticed the problem when I was PXE booting
and had to force the switch to use 100. I don't know what to think since this is a problem before the
kernel even loads. A BIOS update did not fix the issue. Let me know if I can test anything.
Created attachment 161793 [details]
output of dmesg from a boot of the latest F8 rawhide kernel.
Arrived back from holiday did a full update of F8(rawhide) that had been
updated from f8test1 and the new kernel 2.6.23-0.110.rc3.git1.fc8 (i686) has
fixed things for me.
output of dmesg.txt attached.
status changed back to ON_DEV
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
This bug appears to be resolved and I am therefore closing it. If I have erred,
please forgive me and re-open with any additional information you are able to
give. I will then try and assist you if I can.