Bug 250591 - 2.6.22 kernels e1000 gigabit networking started as 10/100
2.6.22 kernels e1000 gigabit networking started as 10/100
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-02 07:30 EDT by David Bentley
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.6.23-0.110.rc3.git1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-23 15:31:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg ouput of current boot to kernel (30.85 KB, text/plain)
2007-08-02 07:30 EDT, David Bentley
no flags Details
dmesg output from a working kernel. (33.00 KB, text/plain)
2007-08-04 18:02 EDT, David Bentley
no flags Details
lspci (1.96 KB, text/plain)
2007-08-06 16:07 EDT, David Bentley
no flags Details
lspci -n (717 bytes, text/plain)
2007-08-06 16:08 EDT, David Bentley
no flags Details
messages.tx of latest boot into initial F8test1 kernel (56.41 KB, text/plain)
2007-08-10 14:25 EDT, David Bentley
no flags Details
output of dmesg from a boot of the latest F8 rawhide kernel. (36.17 KB, text/plain)
2007-08-18 08:24 EDT, David Bentley
no flags Details

  None (edit)
Description David Bentley 2007-08-02 07:30:40 EDT
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 and later.

How reproducible:
Always with both and 44

Steps to Reproduce:
1.boot into 2.6.22 series kernel

Actual results:
Network initialised in 10/100 mode instead of gigabit mode

Expected results:
Network started in gigabit mode

Additional info:dmesg from current boot ( attached.
Comment 1 David Bentley 2007-08-02 07:30:40 EDT
Created attachment 160513 [details]
dmesg ouput of current boot to kernel
Comment 2 Chuck Ebbert 2007-08-02 17:55:24 EDT
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.
Comment 3 David Bentley 2007-08-04 18:02:53 EDT
Created attachment 160700 [details]
dmesg output from a working kernel.

dmesg ouput from the re-installed working kernel as requested.
Comment 4 David Bentley 2007-08-04 18:09:07 EDT
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.
Comment 5 Chuck Ebbert 2007-08-06 12:05:52 EDT
Exactly which model of e1000 is this?
Please post output of 'lspci' and also 'lspci -n'.
Comment 6 David Bentley 2007-08-06 16:07:52 EDT
Created attachment 160768 [details]

lspci as requested
Comment 7 David Bentley 2007-08-06 16:08:42 EDT
Created attachment 160769 [details]
lspci -n

lspci -n as requested
Comment 8 Chuck Ebbert 2007-08-06 17:01:36 EDT
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network
Connection (rev 02)

00:19.0 0200: 8086:104a (rev 02)

Comment 9 Chuck Ebbert 2007-08-06 18:34:57 EDT
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)) ||

Comment 10 Neil Horman 2007-08-09 14:58:06 EDT
What happens if you use ethtool to restart autonegotiation after you bring the
adapter up?  Also, have you tried this with an alternate switch?
Comment 11 David Bentley 2007-08-10 08:56:45 EDT
I do not have another switch to try but all works as expected in F7 with the
original kernel.

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)
Comment 12 Neil Horman 2007-08-10 09:51:02 EDT
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
Comment 13 David Bentley 2007-08-10 12:00:00 EDT
Can you please give a quick explanation of how I do that.
Comment 14 Neil Horman 2007-08-10 12:42:27 EDT
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).
Comment 15 David Bentley 2007-08-10 13:00:58 EDT
Done that but wher is the debug output that you need to see.
Comment 16 Neil Horman 2007-08-10 13:31:33 EDT
Comment 17 David Bentley 2007-08-10 14:25:20 EDT
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
Comment 18 David Bentley 2007-08-10 14:28:25 EDT
Info provided
Status changed to ON_DEV
Comment 19 Neil Horman 2007-08-10 15:40:19 EDT
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.
Comment 20 Peter McNabb 2007-08-16 15:47:20 EDT
I have the same problem on a bunch of HP dc7700 machines using the e1000 module and kernel 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.
Comment 21 David Bentley 2007-08-18 08:24:06 EDT
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.
Comment 22 David Bentley 2007-08-18 08:25:34 EDT
status changed back to ON_DEV
Comment 23 Christopher Brown 2007-09-23 15:31:08 EDT

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.

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