Bug 649570

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.

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 #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.