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 2.6.22.1-33 and later. How reproducible: Always with both 2.6.22.1-33 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 (2.6.22.1-33) attached.
Created attachment 160513 [details] dmesg ouput of current boot to 2.6.22.1-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: RX/TX 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 lspci as requested
Created attachment 160769 [details] lspci -n 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) E1000_DEV_ID_ICH8_IGP_AMT
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)) || !e1000_check_mng_mode(&adapter->hw)) e1000_get_hw_control(adapter);
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 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)
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 autonegotiation. Thanks!
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.
/var/log/messages
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
Info provided 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 2.6.22.1-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
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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.