Bug 649570

Summary: Intel e1000e LAN adaptor fails when ACPI enabled
Product: [Fedora] Fedora Reporter: Patrick O'Callaghan <poc>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: chref, daybrowser, dougsland, dwmw2, gansalmon, i.mortimer, itamar, jonathan, jon+bugzilla.redhat.com, kernel-maint, kmcmartin, lex.lists, madhu.chinakonda, m.gruys, mishu, moorley, peter.hanecak, philipp, rockus_123, smparrish
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 2.6.35.11-83.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-21 03:17:16 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Section of /var/log/messages showing DHCP failure
none
Section /var/log/messages with acpi=off on boot line
none
networking configuration file #1
none
networking configuration file #2
none
output of the rpmbuild -tb e1000e-1.2.20.tar.gz command
none
/boot/grub/menu.lst
none
lshw none

Description Patrick O'Callaghan 2010-11-03 21:36:10 EDT
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.
Comment 1 Patrick O'Callaghan 2010-11-03 21:37:57 EDT
Created attachment 457632 [details]
Section of /var/log/messages showing DHCP failure

DHCPDISCOVER broadcast times out on no reply.
Comment 2 Patrick O'Callaghan 2010-11-03 21:39:49 EDT
Created attachment 457633 [details]
Section /var/log/messages with acpi=off on boot line

Turning ACPI off makes DHCP discovery work normally.
Comment 3 lexual 2010-11-05 08:03:24 EDT
*** Bug 649569 has been marked as a duplicate of this bug. ***
Comment 4 lexual 2010-11-05 08:03:40 EDT
*** Bug 649568 has been marked as a duplicate of this bug. ***
Comment 5 lexual 2010-11-05 08:08:43 EDT
I have the exact same bug, and acpi=off workaround corrects the problem.
Problem doesn't exist in F13.
Comment 6 Michael Gruys 2010-11-06 08:24:38 EDT
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.
Comment 7 Michael Gruys 2010-11-06 13:34:32 EDT
Created attachment 458353 [details]
networking configuration file #1
Comment 8 Michael Gruys 2010-11-06 13:36:28 EDT
Created attachment 458354 [details]
networking configuration file #2
Comment 9 Michael Gruys 2010-11-06 13:36:52 EDT
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
Comment 10 Christof Efkemann 2010-11-06 21:19:00 EDT
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.
Comment 11 Patrick O'Callaghan 2010-11-06 23:46:10 EDT
(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.
Comment 12 Mihai Harpau 2010-11-08 04:09:28 EST
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)
Comment 13 Michael Gruys 2010-11-08 11:56:38 EST
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.
Comment 14 Michael Gruys 2010-11-08 12:27:50 EST
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...
Comment 15 Michael Gruys 2010-11-16 13:53:23 EST
Problem solved after yum updated the following package:

Nov 15 00:42:29 Updated: 12:dhclient-4.2.0-14.P1.fc14.i686
Comment 16 Patrick O'Callaghan 2010-11-16 20:25:11 EST
(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.
Comment 17 Jon Dowland 2010-11-17 11:49:40 EST
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.
Comment 18 Jon Dowland 2010-11-17 11:50:13 EST
In my case the hardware and OS are x86 not amd64.
Comment 19 Michael Gruys 2010-11-18 01:30:53 EST
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
Comment 20 lexual 2010-11-18 04:13:51 EST
I can confirm that the new dhclient rpm does not fix the problem on my machine.
I still need to boot with acpi=off
Comment 21 Patrick O'Callaghan 2010-11-18 06:23:01 EST
(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.
Comment 22 Ken 2010-11-19 04:44:24 EST
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
Comment 23 Jon Dowland 2010-11-19 05:07:20 EST
(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.
Comment 24 Ken 2010-11-19 06:03:26 EST
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
Comment 25 Michael Gruys 2010-11-19 10:47:42 EST
(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!
Comment 26 Patrick O'Callaghan 2010-11-19 18:41:11 EST
(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.
Comment 27 Patrick O'Callaghan 2010-11-19 19:09:16 EST
(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.
Comment 28 Christof Efkemann 2010-11-19 19:23:05 EST
And I'd like to add that version 1.2.20 of e1000e works as well without problems here (Intel DG965OT mainboard, btw.).
Comment 29 Patrick O'Callaghan 2010-11-19 22:20:06 EST
(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.
Comment 30 Michael Gruys 2010-11-20 03:07:26 EST
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.
Comment 31 Michael Gruys 2010-11-20 03:08:40 EST
Created attachment 461701 [details]
output of the rpmbuild -tb e1000e-1.2.20.tar.gz command
Comment 32 Ken 2010-11-20 03:35:12 EST
(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
Comment 33 Michael Gruys 2010-11-20 04:47:21 EST
(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.
Comment 34 Michael Gruys 2010-11-20 05:06:48 EST
(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.
Comment 35 Patrick O'Callaghan 2010-11-20 11:03:36 EST
(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".
Comment 36 Michael Gruys 2010-11-20 11:46:39 EST
(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
Comment 37 Michael Gruys 2010-12-08 15:44:46 EST
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
Comment 38 Michael Gruys 2010-12-08 15:45:12 EST
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
Comment 39 Philip Prindeville 2010-12-08 18:55:30 EST
(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.
Comment 40 Kyle McMartin 2010-12-09 11:30:20 EST
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
Comment 41 Christof Efkemann 2010-12-09 12:34:40 EST
(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
Comment 42 Michael Gruys 2010-12-09 12:42:32 EST
(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.
Comment 43 Philip Prindeville 2010-12-09 13:07:44 EST
(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.
Comment 44 Michael Gruys 2010-12-09 13:30:12 EST
Thanks. I hope I will find the time (and knowledge) to try the same test with my system. I will post it.
Comment 45 Michael Gruys 2010-12-09 13:39:40 EST
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?
Comment 46 Philip Prindeville 2010-12-09 14:36:40 EST
(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.
Comment 47 Kyle McMartin 2010-12-09 14:42:57 EST
So grab them manually.
Comment 48 Christof Efkemann 2010-12-09 15:08:59 EST
(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
Comment 49 Michael Gruys 2010-12-09 15:14:45 EST
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
Comment 50 Mihai Harpau 2010-12-09 18:56:00 EST
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).
Comment 51 Michael Gruys 2010-12-10 11:31:17 EST
Seems there are different adapters for nearly the same motherboards. Can one letter make a difference (82566DC contra 82566DM) ?
Comment 52 Kyle McMartin 2010-12-10 11:41:07 EST
Michael, can you retest with pcie_aspm=off using the 2.6.37 kernel?
Comment 53 Kyle McMartin 2010-12-10 11:44:02 EST
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.
Comment 54 Michael Gruys 2010-12-10 12:11:48 EST
(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
Comment 55 Michael Gruys 2010-12-10 12:15:26 EST
Created attachment 468016 [details]
/boot/grub/menu.lst

kernel parameters 2.6.37-0.rc5.git2.1.fc15.i686
Comment 56 Kyle McMartin 2010-12-10 12:25:55 EST
http://marc.info/?l=e1000-devel&m=128559532413150&w=2

Looks to be reporting a similar issue.
Comment 57 Kyle McMartin 2010-12-10 12:28:22 EST
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?
Comment 58 Michael Gruys 2010-12-10 12:47:27 EST
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)
Comment 59 Michael Gruys 2010-12-10 12:48:41 EST
Created attachment 468023 [details]
lshw

my hardware
Comment 60 Michael Gruys 2010-12-23 02:20:36 EST
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)
Comment 61 rockus 2010-12-24 16:04:22 EST
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.
Comment 62 Michael Gruys 2010-12-24 16:15:05 EST
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...
Comment 63 Seth Abraham 2011-01-08 19:03:22 EST
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?
Comment 64 Michael Gruys 2011-01-09 03:36:04 EST
follow the instructions of comment #32
You can download the package at http://e1000.sf.net/
Comment 65 rockus 2011-02-19 10:24:20 EST
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.
Comment 66 Michael Gruys 2011-02-19 10:34:35 EST
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
Comment 67 Patrick O'Callaghan 2011-02-19 12:00:34 EST
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.
Comment 68 rockus 2011-02-19 12:36:00 EST
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.