Description of problem: In the default ACPI=on mode, the local Ethernet will not connect Version-Release number of selected component (if applicable): kernel-2.6.35.6-48.fc14.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot Fedora 14 with default options 2.LAN fails to connect 3. Actual results: No connection Expected results: Connection Additional info: The problem manifests as a failure to get an response to DHCPDISCOVER packets (as traced via /var/log/messages). Fedora 13 on the identical hardware and network has no problem, so this may be a kernel regression. Setting ACPI=off in the boot options fixes the issue.
Created attachment 457632 [details] Section of /var/log/messages showing DHCP failure DHCPDISCOVER broadcast times out on no reply.
Created attachment 457633 [details] Section /var/log/messages with acpi=off on boot line Turning ACPI off makes DHCP discovery work normally.
*** Bug 649569 has been marked as a duplicate of this bug. ***
*** Bug 649568 has been marked as a duplicate of this bug. ***
I have the exact same bug, and acpi=off workaround corrects the problem. Problem doesn't exist in F13.
I have the exact same bug, and acpi=off workaround DOES NOT corrects the problem. Please let me know what additional info you need. I switched back to FC13 (in my grub menu) and networking is OK.
Created attachment 458353 [details] networking configuration file #1
Created attachment 458354 [details] networking configuration file #2
Suddenly after a new reboot, I have correctly working networking connection! Maybe it has to do because I make use of a bridge. An ifconfig reveals: r0 Link encap:Ethernet HWaddr 00:19:D1:1A:A8:10 inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::219:d1ff:fe1a:a810/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:492 errors:0 dropped:0 overruns:0 frame:0 TX packets:575 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:123680 (120.7 KiB) TX bytes:83536 (81.5 KiB) eth0 Link encap:Ethernet HWaddr 00:19:D1:1A:A8:10 inet6 addr: fe80::219:d1ff:fe1a:a810/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:495 errors:0 dropped:0 overruns:0 frame:0 TX packets:577 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:130758 (127.6 KiB) TX bytes:83396 (81.4 KiB) Interrupt:20 Memory:e2200000-e2220000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:144 errors:0 dropped:0 overruns:0 frame:0 TX packets:144 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:14706 (14.3 KiB) TX bytes:14706 (14.3 KiB) virbr0 Link encap:Ethernet HWaddr 92:CE:CA:B1:4D:C7 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:54 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:8197 (8.0 KiB) my two network configuration files I have included: /etc/sysconfig/network-scripts/ifcfg-br0 /etc/sysconfig/network-scripts/ifcfg-eth0 maybe these two cause this random behavior of the networking stability? uname -a reveals: Linux 2.6.35.6-48.fc14.i686.PAE #1 SMP Fri Oct 22 15:27:53 UTC 2010 i686 i686 i386 GNU/Linux Anyway it is working now
Version 1.2.17 of the e1000e driver available on e1000.sf.net seems to fix this issue. I compiled it myself for kernel 2.6.35.6-48.fc14.x86_64 and now the NIC is working fine.
(In reply to comment #10) > Version 1.2.17 of the e1000e driver available on e1000.sf.net seems to fix this > issue. I compiled it myself for kernel 2.6.35.6-48.fc14.x86_64 and now the NIC > is working fine. Good to know. I don't really care about not having ACPI so I guess I'll wait till this percolates through to the dsitro.
In my case it was enough to put pcie_aspm=off in kernel grub line to have Intel e1000e netcard working. 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC Gigabit Network Connection [8086:104b] (rev 02)
That explains why in (In reply to comment #12) > In my case it was enough to put pcie_aspm=off in kernel grub line to have Intel > e1000e netcard working. > > 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC Gigabit Network > Connection [8086:104b] (rev 02) Thank you. That explains why in the first place "my" acpi=off workaround in the kernel grub failed. I had to use the pcie_aspm=off. Never knew there are multiple acpi options possible.
Last info: Still no luck with also the pcie_aspm=off option in the kernel grub line on kernel 2.6.35.6-48.fc14.i686.PAE #1 SMP. Switched back to fc13 2.6.34.7-61.fc13.i686.PAE #1 SMP kernel and no problems. Nov 8 18:20:48 droef kernel: e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2 Nov 8 18:20:48 droef kernel: e1000e: Copyright (c) 1999 - 2009 Intel Corporation motherboard: DQ965GF maybe this motherboard is not supported anymore...
Problem solved after yum updated the following package: Nov 15 00:42:29 Updated: 12:dhclient-4.2.0-14.P1.fc14.i686
(In reply to comment #15) > Problem solved after yum updated the following package: > > Nov 15 00:42:29 Updated: 12:dhclient-4.2.0-14.P1.fc14.i686 Confirmed in my case. So it turned out not to be a driver problem after all.
This prevents me from installing F14 via kickstart. acpi=off ks=<my file> results in a kernel panic. pcie_aspm=off did not resolve the problem. acpi=off noapic ks=<my file> gets me past the kernel panic but does not resolve the DHCP issue. With no ks= I can get a /bin/sh on VT2. Having done that, if I attempt a manual configuration of the interface and routing table I still can't talk, so I'm not sure it is a dhclient bug in my case. e1000e is the loaded module for the interface. I tried removing it and loading e1000 on an off-chance but I don't end up with a network device that way.
In my case the hardware and OS are x86 not amd64.
After a reboot it unfortunately happened again: no networking. I switched back to Linux 2.6.34.7-61.fc13.i686.PAE #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 i386 GNU/Linux and no problems
I can confirm that the new dhclient rpm does not fix the problem on my machine. I still need to boot with acpi=off
(In reply to comment #19) > After a reboot it unfortunately happened again: no networking. I switched back > to > Linux 2.6.34.7-61.fc13.i686.PAE #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 > i386 GNU/Linux and no problems Same here. Dhclient doesn't seem to be the culprit after all. It did work the first time but now doesn't. I put "acpi=off" back into the Grub line and it works again.
Have a DG965WH Intel motherboard with the same problem. Downloaded e1000e-12.17.tar.gz ran a make install, problem solved. NOTE: The original e1000e.ko module was 207Kb the new was 2.9Mb
(In reply to comment #22) > NOTE: The original e1000e.ko module was 207Kb the new was 2.9Mb Your hand-built one probably hasn't been stripped, which would explain the size difference.
(In reply to comment #24) > Have a DG965WH Intel motherboard with the same problem. > > Downloaded e1000e-12.17.tar.gz ran a make install, problem solved. > > NOTE: The original e1000e.ko module was 207Kb the new was 2.9Mb Thank you!
(In reply to comment #22) > Have a DG965WH Intel motherboard with the same problem. > > Downloaded e1000e-12.17.tar.gz ran a make install, problem solved. > > NOTE: The original e1000e.ko module was 207Kb the new was 2.9Mb Please indicate a URL for this so others can try it.
(In reply to comment #26) > (In reply to comment #22) > > Have a DG965WH Intel motherboard with the same problem. > > > > Downloaded e1000e-12.17.tar.gz ran a make install, problem solved. > > > > NOTE: The original e1000e.ko module was 207Kb the new was 2.9Mb > > Please indicate a URL for this so others can try it. Apologies, I just noticed Comment 10 (the URL is http://e1000.sf.net). The latest version is 1.2.20.
And I'd like to add that version 1.2.20 of e1000e works as well without problems here (Intel DG965OT mainboard, btw.).
(In reply to comment #28) > And I'd like to add that version 1.2.20 of e1000e works as well without > problems here (Intel DG965OT mainboard, btw.). Yes, using it right now.
Unfortunately installing the e1000e-1.2.20.tar.gz file did not solve the problem. (yes I have rebooted, after the installation) As said in comment #14 my motherboard is DQ965GF. I have executed as root the following command: rpmbuild -tb e1000e-1.2.20.tar.gz All went well. I have included an attachment with the output of the command. Maybe someone with the same motherboard can help me? Unfortunately hwinfo is not available in the f14 repositories (and the http://www.rpmfind.net/linux/rpm2html/search.php?query=hwinfo RPM is possible a rootkit, I do not trust this site) so I cannot give other hardware information about my system. If any other (configuration) info is needed please let me know.
Created attachment 461701 [details] output of the rpmbuild -tb e1000e-1.2.20.tar.gz command
(In reply to comment #31) > Created attachment 461701 [details] > output of the rpmbuild -tb e1000e-1.2.20.tar.gz command Your going about it the wrong way, execute as root user:- tar -xvf e1000e-1.2.20.tar.gz cd e1000e-1.2.20/src/ make install
(In reply to comment #32) > (In reply to comment #31) > > Created attachment 461701 [details] [details] > > output of the rpmbuild -tb e1000e-1.2.20.tar.gz command > > Your going about it the wrong way, execute as root user:- > tar -xvf e1000e-1.2.20.tar.gz > cd e1000e-1.2.20/src/ > make install Thanks for your reply. It works very well now. Thanks to your help. In the past I compiled a couple of packages by using: ./configure make (or make -j2 to use my dual core power) and if I wanted to install those packages I executed (as root): make install But this time I thought there is a new ('next generation' way) to compile and install things: rpmbuild -tb But I guess I should read the man page of this command to learn what it actually does :-) Anyway. Thanks again.
(In reply to comment #30) > Unfortunately hwinfo is not available in the f14 repositories (and the I found the lshw tool which is in the fc14 repositories.
(In reply to comment #31) > Created attachment 461701 [details] > output of the rpmbuild -tb e1000e-1.2.20.tar.gz command All that does is build the rpm and leave it ~/rpmbuild/RPMS. You then have to install it as root: sudo rpm -ihv the-rpm-you-just-built.rpm or better still sudo yum --nogpg install the-rpm-you-just-built.rpm This is better because yum knows about it and when at some future date a later version appears in the Fedora repos, you'll get it automatically via "yum update".
(In reply to comment #35) > (In reply to comment #31) > > Created attachment 461701 [details] [details] > > output of the rpmbuild -tb e1000e-1.2.20.tar.gz command > > All that does is build the rpm and leave it ~/rpmbuild/RPMS. You then have to > install it as root: > > sudo rpm -ihv the-rpm-you-just-built.rpm > > or better still > > sudo yum --nogpg install the-rpm-you-just-built.rpm > > This is better because yum knows about it and when at some future date a later > version appears in the Fedora repos, you'll get it automatically via "yum > update". will capture this... thx
FY: To day I received automatically the following updates Dec 08 16:13:40 Updated: mdadm-3.1.3-0.git20100804.2.fc14.i686 Dec 08 16:13:42 Updated: yp-tools-2.11-2.fc14.i686 Dec 08 16:13:47 Updated: libicu-4.4.1-6.fc14.i686 Dec 08 16:13:50 Updated: telepathy-logger-0.1.7-1.fc14.i686 Dec 08 16:13:56 Updated: binutils-2.20.51.0.7-6.fc14.i686 Dec 08 16:14:02 Updated: logwatch-7.3.6-58.fc14.noarch After these updates, you have to install again the (older) e1000e-1.2.20.tar.gz version A the description of the yum info on these tools unfortunately not reveal enough for me what these packages do. Too difficult to get the relation with e1000e module
FY: Today I received automatically the following updates Dec 08 16:13:40 Updated: mdadm-3.1.3-0.git20100804.2.fc14.i686 Dec 08 16:13:42 Updated: yp-tools-2.11-2.fc14.i686 Dec 08 16:13:47 Updated: libicu-4.4.1-6.fc14.i686 Dec 08 16:13:50 Updated: telepathy-logger-0.1.7-1.fc14.i686 Dec 08 16:13:56 Updated: binutils-2.20.51.0.7-6.fc14.i686 Dec 08 16:14:02 Updated: logwatch-7.3.6-58.fc14.noarch After these updates, you have to install again the (older) e1000e-1.2.20.tar.gz version A the description of the yum info on these tools unfortunately not reveal enough for me what these packages do. Too difficult to get the relation with e1000e module
(In reply to comment #38) > A the description of the yum info on these tools unfortunately not reveal > enough for me what these packages do. Too difficult to get the relation with > e1000e module You might try: rpm -q --filesbypkg pkgname to see what it installs... this might be more useful. But nothing in your list should be replacing kernel modules. Only "kernel" does that.
Hi, Please try either the 2.6.36 kernel from rawhide (which you should be able to easily install from koji) or the 2.6.37-rc5 kernel from http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo and let us know if it helps at all. If so, we can bisect to find the fix and then fix the F-14 kernel. Thanks, Kyle
(In reply to comment #40) > Hi, > > Please try either the 2.6.36 kernel from rawhide (which you should be able to > easily install from koji) or the 2.6.37-rc5 kernel from > http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo and let us > know if it helps at all. If so, we can bisect to find the fix and then fix the > F-14 kernel. I just tried both of them, and with both the e1000e module is working properly here. Cheers, Christof
(In reply to comment #41) > (In reply to comment #40) > > Hi, > > > > Please try either the 2.6.36 kernel from rawhide (which you should be able to > > easily install from koji) or the 2.6.37-rc5 kernel from > > http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo and let us > > know if it helps at all. If so, we can bisect to find the fix and then fix the > > F-14 kernel. > > I just tried both of them, and with both the e1000e module is working properly > here. > > Cheers, > Christof My motherboard is DQ965GF. It contains a description: Ethernet interface product: 82566DM Gigabit Network Connection vendor: Intel Corporation (info from lshw) I am curious of your test was on this configuration? Thanks in advance.
(In reply to comment #42) > My motherboard is DQ965GF. > It contains a > > description: Ethernet interface > product: 82566DM Gigabit Network Connection > vendor: Intel Corporation > (info from lshw) > > I am curious of your test was on this configuration? > > Thanks in advance. I have a Dell Optiplex 745C which uses that same NIC (if not the very same motherboard... I'm not in that lab right now so I can't tell you). The rawhide kernel seems to work just fine.
Thanks. I hope I will find the time (and knowledge) to try the same test with my system. I will post it.
I have placed the contents of http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo in /etc/yum.repos.d/fedora-kernel.repo and did a 'yum update' I get the following error message: http://repos.fedorapeople.org/repos/kyle/kernel/fedora-14/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404 : http://repos.fedorapeople.org/repos/kyle/kernel/fedora-14/i386/repodata/repomd.xml Trying other mirror. Setting up Update Process No Packages marked for Update Is this the only thing I had to do?
(In reply to comment #45) > I have placed the contents of > http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo > in /etc/yum.repos.d/fedora-kernel.repo and did a 'yum update' > > I get the following error message: > > http://repos.fedorapeople.org/repos/kyle/kernel/fedora-14/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404 : > http://repos.fedorapeople.org/repos/kyle/kernel/fedora-14/i386/repodata/repomd.xml > Trying other mirror. > Setting up Update Process > No Packages marked for Update > > Is this the only thing I had to do? That's a problem at Kyle's end, since he's only building for fedora-15.
So grab them manually.
(In reply to comment #42) > [...] > My motherboard is DQ965GF. > It contains a > > description: Ethernet interface > product: 82566DM Gigabit Network Connection > vendor: Intel Corporation > (info from lshw) > > I am curious of your test was on this configuration? No, mine is a DG965OT. The network interface is: description: Ethernet interface product: 82566DC Gigabit Network Connection vendor: Intel Corporation
I downloaded and installed http://repos.fedorapeople.org/repos/kyle/kernel/fedora-15/i386/kernel-2.6.37-0.rc5.git2.1.fc15.i686.rpm. The installation went well. But after reboot I had NO working network adapter! :-(( After installing the (older) e1000e-1.2.20.tar.gz again version I had after a reboot a fine working network adapter! So I'm afraid it is not solved in the kernel-2.6.37-0.rc5.git2.1.fc15.i686 .... My time is limited this evening. Must get up early tomorrow. Will keep following this thread. Thanks till now on for your suggestions. Bye
With kernel-2.6.36.2-12.rc1.fc15.x86_64.rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=208434 I have an e1000e adapter fully functional. My motherboard is Intel DG965SS and network adapter is 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC Gigabit Network Connection [8086:104b] (rev 02).
Seems there are different adapters for nearly the same motherboards. Can one letter make a difference (82566DC contra 82566DM) ?
Michael, can you retest with pcie_aspm=off using the 2.6.37 kernel?
It looks like there were two issues here, one which was a missing mdelay in the bring-up path in 2.6.35, which was fixed in 2.6.37, and possibly that our aggressive pcie aspm settings are running afoul of e1000e.
(In reply to comment #52) > Michael, can you retest with pcie_aspm=off using the 2.6.37 kernel? I Just have booted again with this setting in the boot parameters of the 2.6.37 kernel. Sorry to let you know: *No* networking :-(. I have included my /boot/grub/menu.lst for showing my kernel settings
Created attachment 468016 [details] /boot/grub/menu.lst kernel parameters 2.6.37-0.rc5.git2.1.fc15.i686
http://marc.info/?l=e1000-devel&m=128559532413150&w=2 Looks to be reporting a similar issue.
If you have the option to disable AMT in your BIOS, as suggested by that thread, could you try that and let us know if it helps at all?
I have not the option in my BIOS to disable AMT. The only option I saw was CMT, but that has to do with the cores of the CPU. I have include a copy of the output of the lshw command (executed as root). I hope this can reveal more about my hardware (and BIOS)
Created attachment 468023 [details] lshw my hardware
Same issue with Linux 2.6.35.10-72.fc14.i686.PAE #1 SMP Mon Dec 20 21:47:25 UTC 2010 i686 i686 i386 GNU/Linux (this morning automatically downloaded & rebooted)
I have the same issue with the same issue with Intel 82566DC. Fedora 13 eth0 connects fine, but any thing with Fedora 14 failed, including the latest Fedora 14 kernel updates (2.5.35-10). Once in a while you can make it work by filling in the nameserver in resolv.conf, restart both network and nameserver. But after reboot, eth0 failed again.
Yes, The problem is also solved when applying the steps of comment #32 But you have to do this again each time after an update of the e1000e module...
I also have this network problem with 2.6.35.10-74.fc14.x86_64 kernel, and dhclient-4.2.0-16.P2. I am using an Intel motherboard with integrated graphics. The Ethernet (as reported by lspci) is: 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02) I have observed: 1) the pcie_aspm=off acpi=off workaround works most of the time. It occasionally fails. 2) I tried vmlinuz-2.6.37-0.rc5.git2.1.fc15.i686 kernel and had the machine freeze during boot, while probing hardware 3) vmlinuz-2.6.37-0.rc5.git2.1.fc15.i686 with pcie_aspm=off allowed the machine to boot, but did not get the network up. 4) On configurations where the network does not come up, I see the log messages indicating that DHCPDISCOVER message was not responded to, however I was able to see the proper network config information in the cached files. 5) When I tried to manually configure the network, I was unable to get the network routes to get proper function 6) On configs where the network did not come up, I often saw IRQ conflicts between the network card and this the audio device (00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)) Is the exact mechanism of this bug understood? Is there any other suggestions for boot with F14, keeping the network functional and still have ACPI?
follow the instructions of comment #32 You can download the package at http://e1000.sf.net/
Looks like this issue is fixed with the 2.6.35.11-83.fc14.x86_64 updates. Can someone also confirms. It has taken so long. Thanks.
Looks like it also fixed on: Linux 2.6.35.11-83.fc14.i686.PAE #1 SMP Mon Feb 7 06:57:55 UTC 2011 i686 i686 i386 GNU/Linux
2.6.35.11-83.fc14.x86_64(In reply to comment #65) > Looks like this issue is fixed with the 2.6.35.11-83.fc14.x86_64 updates. Can > someone also confirms. It has taken so long. > > Thanks. Confirmed. I think it might even have started working with a previous version, I simply hadn't noticed, i.e. I haven't had to compile the e1000e driver for some time now.
Thanks both for the confirmation. As for me, it still doesn't work as late as 2.6.35.10-74.fc14.x86_64, which is the update prior to this last one.