DHCPcd problem with latest kernel (vanilla)

Message

abrown118321 · Post by **abrown118321** » Mon Aug 02, 2010 3:18 pm

Hi all fellow gentoo users,

Today, as I always do with a new release, I upgraded my kernel. On rebooting into 2.6.35 my network card gets recognized, but when the dhcpcd startup script runs, it times out. The NIC fails to receive an ip. Rebooting back to 2.6.34 all seems good. (I get an ip) This seems to me a kernel problem with dhcpcd, but asking out there for advice.

Etal · Post by **Etal** » Mon Aug 02, 2010 4:24 pm

I have a similar problem. With 2.6.35, when I boot the machine, I do not get an IP address.

However, if I stop and then restart dhcpcd (dhcpcd -k ; dhcpcd), I do get the IP.

It's pretty annoying...

idella4 · Post by **idella4** » Tue Aug 03, 2010 12:41 pm

AM088 & abrown118321;

first post of call would be to look at the boot log info; demsg or ? messages in /var/log/.
Try looking with grep eth0, grep dhcp /var/log/the-above.
Try /etc/init.d/net.[iface] restart followed by an immediate tail /var/log/dmesg; post

Etal · Post by **Etal** » Tue Aug 03, 2010 2:40 pm

Here's what I get for Linux 2.6.34.1:

Code: Select all

Aug  2 14:48:03 tuz dhcpcd[972]: version 5.2.6 starting
Aug  2 14:48:03 tuz dhcpcd[972]: forked to background, child pid 979
Aug  2 14:48:05 tuz dhcpcd[979]: eth0: broadcasting for a lease
Aug  2 14:48:05 tuz dhcpcd[979]: wlan0: waiting for carrier
Aug  2 14:48:05 tuz klogd: wlan0: authenticate with XX:XX:XX:XX:XX:XX (try 1)
Aug  2 14:48:05 tuz klogd: wlan0: authenticated
Aug  2 14:48:05 tuz klogd: wlan0: associate with XX:XX:XX:XX:XX:XX (try 1)
Aug  2 14:48:05 tuz klogd: wlan0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431 status=0 aid=3)
Aug  2 14:48:05 tuz klogd: wlan0: associated
Aug  2 14:48:05 tuz dhcpcd[979]: wlan0: carrier acquired
Aug  2 14:48:05 tuz dhcpcd[979]: wlan0: rebinding lease of 192.168.1.2
Aug  2 14:48:05 tuz dhcpcd[979]: wlan0: acknowledged 192.168.1.2 from 192.168.1.1
Aug  2 14:48:05 tuz dhcpcd[979]: wlan0: checking for 192.168.1.2
Aug  2 14:48:10 tuz dhcpcd[979]: wlan0: leased 192.168.1.2 for infinity

Here's what I get with Linux 2.6.35:

Code: Select all

Aug  2 15:17:08 tuz dhcpcd[768]: version 5.2.6 starting
Aug  2 15:17:08 tuz dhcpcd[768]: forked to background, child pid 773
Aug  2 15:17:09 tuz dhcpcd[773]: eth0: broadcasting for a lease
Aug  2 15:17:09 tuz dhcpcd[773]: wlan0: waiting for carrier
Aug  2 15:17:10 tuz klogd: wlan0: authenticate with XX:XX:XX:XX:XX:XX (try 1)
Aug  2 15:17:10 tuz klogd: wlan0: authenticated
Aug  2 15:17:10 tuz klogd: wlan0: associate with XX:XX:XX:XX:XX:XX (try 1)
Aug  2 15:17:10 tuz klogd: wlan0: associate with XX:XX:XX:XX:XX:XX (try 2)
Aug  2 15:17:10 tuz klogd: wlan0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431 status=0 aid=3)
Aug  2 15:17:10 tuz klogd: wlan0: associated
[I restart dhcpcd]
Aug  2 15:17:55 tuz dhcpcd[773]: received SIGTERM, stopping
Aug  2 15:17:55 tuz dhcpcd[773]: wlan0: removing interface
Aug  2 15:17:55 tuz dhcpcd[773]: eth0: removing interface
Aug  2 15:17:55 tuz dhcpcd[1185]: version 5.2.6 starting
Aug  2 15:17:55 tuz dhcpcd[1185]: forked to background, child pid 1186
Aug  2 15:17:55 tuz dhcpcd[1186]: eth0: broadcasting for a lease
Aug  2 15:17:55 tuz dhcpcd[1186]: wlan0: rebinding lease of 192.168.1.2
Aug  2 15:17:55 tuz dhcpcd[1186]: wlan0: acknowledged 192.168.1.2 from 192.168.1.1
Aug  2 15:17:55 tuz dhcpcd[1186]: wlan0: checking for 192.168.1.2
Aug  2 15:18:00 tuz dhcpcd[1186]: wlan0: leased 192.168.1.2 for infinity

So the difference is that with 2.6.35, it doesn't acquitre carrier, and waits indefinitely ("wlan0: carrier acquired")

Post by **asturm** » Tue Aug 03, 2010 2:44 pm

same issue with my e1000e wired ethernet connection since 2.6.35

Etal · Post by **Etal** » Tue Aug 03, 2010 2:48 pm

Here's my card:

Code: Select all

0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

idella4 · Post by **idella4** » Tue Aug 03, 2010 3:25 pm

AM088,
I had a similar thing with 2.6.30 - 2.6.31 re the wireless. I can't provide a fix, but I might provide a workaround.

Code: Select all

Aug  2 15:17:55 tuz dhcpcd[773]: received SIGTERM, stopping 
Aug  2 15:17:55 tuz dhcpcd[773]: wlan0: removing interface 
Aug  2 15:17:55 tuz dhcpcd[773]: eth0: removing interface

says you have a wired and a wireless. On my gentoo, it doesn't work either, but I figure it's because having two ifaces in ifconfig are just counteracting one another. I don't really care as to how and why. Currently I just do ifconfig eth0 down followed by dhclient, only because I don't consider it a problem since I can get it going, but if you want it to produce during bootup, just disable the undesired interface from /etc/conf.d/net which has to have a config to support the interfaces to work. I'm 95% sure that will deliver, otherwise, I don't know.

xibo · Post by **xibo** » Tue Aug 03, 2010 3:35 pm

i have a core2 and an atom, former has an e1000 and an e1000e, later an e1000 and an r8168 .

The core2 can will successfully start the e1000e adapter and timeout the e1000's carrier signal while __booting__, then successfully start the e1000, too, when nfsmount service pulls the eth1 dependency.
Restarting either of the ethernet adapters will fail, trying it again will succeed, when kernel is compiled with -O2 . When using -Os, it will always fail [ rc6 ], including at system startup. I was using gcc-4.5.0 though a try on the day 4.5.1 was released showed no difference. I'll try updating to 2.6.35-"stable" later today...

On the Atom both cards are working properly, i can restart them whenever i want and it will work, independent of CONFIG_CC_OPTIMIZE_FOR_SIZE. The Atom is using -march=core2 for both the kernel and all packages installed ( same packages and same versions as the core2 ), due to severe problems with -march=atom ( there s other threads about that somewhere here ), so it's not a problem of gcc's code generation.

I also noticed 2.6.35-rcX kernels kernel panic-ing when attempting to mount -o vers=3,sec=krb5 an nfs share. Not sure whether it's related though, as the backtrace indicates it's i915/nouveau dying...

EDIT:
kernel-2.6.35 "stable"

Code: Select all

[    9.284986] ADDRCONF(NETDEV_UP): eth0: link is not ready
[    9.292974] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[    9.294715] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   19.890048] eth0: no IPv6 routers present
[...]
[   66.005632] ADDRCONF(NETDEV_UP): eth1: link is not ready

the long period between eth0 and eth1 indicates me having forgotten to make modules_install prior to rebooting -.-"

trying to restart the e1000 to dhcpcd still keeps failing. can't provide syslog 'cause i'm not using it on my desktop's 4 days old installation.

Etal · Post by **Etal** » Tue Aug 03, 2010 4:14 pm

Looks like it might be a bug in dhcpcd:

https://bugzilla.kernel.org/show_bug.cgi?id=16187#c12

Post by **mpagano** » Wed Aug 04, 2010 12:21 pm

I think we just might need a version bump.

From: http://roy.marples.name/archives/dhcpcd ... /0218.html

* Use dynamically sized buffers for reading kernel link events
Fixes carrier status on Linux-2.6.35 64bit kernels

I've pinged maintainers in IRC, but can't test the new version since I am remote from my machines.

Etal · Post by **Etal** » Wed Aug 04, 2010 1:38 pm

That fixed it for me

Post by **asturm** » Wed Aug 04, 2010 1:42 pm

you beat me to it

MaDDeePee · Post by **MaDDeePee** » Sat Aug 07, 2010 8:37 pm

Thanks a lot!

firephoto · Post by **firephoto** » Wed Aug 11, 2010 5:49 pm

I have had random luck getting my e1000e to work since 2.6.35 was out but it just wouldn't work today no matter how many restarts and ups and downs I did to eth0 and dhcpcd and even running static configs. I get the carrier link up down randomness once the network tries to come up and until I unload the module.

Back to 2.6.34 for now and the 35.1 update didn't help.

xibo · Post by **xibo** » Wed Aug 11, 2010 8:32 pm

firephoto wrote:I have had random luck getting my e1000e to work since 2.6.35 was out but it just wouldn't work today no matter how many restarts and ups and downs I did to eth0 and dhcpcd and even running static configs. I get the carrier link up down randomness once the network tries to come up and until I unload the module.

Back to 2.6.34 for now and the 35.1 update didn't help.

...update your dhcpcd package...

firephoto · Post by **firephoto** » Wed Aug 11, 2010 8:58 pm

xibo wrote:
firephoto wrote:I have had random luck getting my e1000e to work since 2.6.35 was out but it just wouldn't work today no matter how many restarts and ups and downs I did to eth0 and dhcpcd and even running static configs. I get the carrier link up down randomness once the network tries to come up and until I unload the module.

Back to 2.6.34 for now and the 35.1 update didn't help.
...update your dhcpcd package...

On ~arch 64bit so I've done that with limited results... restarting services allowed eth0 to work finally till a reboot today when nothing seemed to get it going. The 35.1 update changed something again or something still isn't correct. 2.6.34 works with a static or dhcp setup with no issues.

I've also tried the e1000e as built in and as a module and also disabled ipv6 in the kernel and USE since it wasn't needed.

tooler · Post by **tooler** » Mon Aug 16, 2010 1:54 pm

I have the same problem on ~arch amd64, hardware is some older HP desktop with Intel Corporation 82566DM Gigabit Network Connection which was working for me with e1000e driver up to gentoo-sources 2.6.35-r1. I have also recent dhcpcd 5.2.7 and I recompiled iproute2 too, but I don't think it is dhcpcd related since the network configured manualy don't work either. I get network is unreachable error although I see some packets on interface with tcpdump (strange). I don't see anything ineresting regarding this issue in dmesg output. Strange it seems that network was working with 2.6.35-r1 at least once, after I booted new kernel and realized that I need to compile nvidia drivers for new kernel since my X won't start without it (drivers was dowloaded from network, so it was working).

darkphader · Post by **darkphader** » Mon Aug 16, 2010 2:36 pm

tooler wrote:I have the same problem on ~arch amd64, hardware is some older HP desktop with Intel Corporation 82566DM Gigabit Network Connection which was working for me with e1000e driver up to gentoo-sources 2.6.35-r1.

Have you tried the e1000 module instead of the e1000e?
Is there a BIOS upgrade available for the system?
The 82541PI and the 82573L work here with the e1000 and e1000e respectively.

tooler · Post by **tooler** » Tue Aug 17, 2010 2:20 pm

darkphader wrote:
tooler wrote:I have the same problem on ~arch amd64, hardware is some older HP desktop with Intel Corporation 82566DM Gigabit Network Connection which was working for me with e1000e driver up to gentoo-sources 2.6.35-r1.
Have you tried the e1000 module instead of the e1000e?
Is there a BIOS upgrade available for the system?
The 82541PI and the 82573L work here with the e1000 and e1000e respectively.

I have now updated bios and Intel PRO/1000 firmware (it's HP dc7700 desktop PC) - didn't helped. Module e1000 does not work either (it does not even create device, I tried some other intel gigabit driver too), I remember I tried e1000 when I got this computer in time of 2.6.28 and since then up to 2.6.34 I'm using e1000e without any problems (it's on PCIe bus). I have checked log on cisco switch on the other end and I see the interface is flapping:

Code: Select all

Aug 17 14:38:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up
Aug 17 14:38:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
Aug 17 14:38:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up
Aug 17 14:38:26: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
Aug 17 14:38:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up

but I can't suspect its issue on cisco switch since the configuration is still the same but what has changed is my kernel version. I suspect the problem may be rooted in the recent network changes in 2.6.35 and only in some special cases/configurations. I will not waste more time with this, older kernel works just fine. Here is relevant log output which looks exactly the same as with 2.6.34 (except that dhcpcd get acknowledgement from dhcp server):

Code: Select all

Aug 17 15:34:54 kernel: e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:19:bb:46:34:12
Aug 17 15:34:54 kernel: e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
Aug 17 15:34:54 kernel: e1000e 0000:00:19.0: eth0: MAC: 6, PHY: 6, PBA No: 1063ff-0ff
Aug 17 15:34:54 kernel: e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
Aug 17 15:34:54 kernel: e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
Aug 17 15:34:54 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug 17 15:34:54  dhcpcd[4718]: eth0: waiting for carrier
Aug 17 15:34:55  kernel: e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Aug 17 15:34:55  kernel: e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO
Aug 17 15:34:55  kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 17 15:34:55  dhcpcd[4718]: eth0: carrier acquired
Aug 17 15:34:55  dhcpcd[4718]: eth0: rebinding lease of 10.20.20.23

darkphader · Post by **darkphader** » Tue Aug 17, 2010 2:29 pm

tooler wrote:I remember I tried e1000 when I got this computer in time of 2.6.28 and since then up to 2.6.34 I'm using e1000e without any problems (it's on PCIe bus).

Wasn't sure about the bus for that model - e1000e should be the correct driver. I did run across a thread where there were some issues (although with earlier kernels) where when the e1000 was built-in it would interfere with the e1000e, but I'm pretty sure that was solved.

wuzzerd · Post by **wuzzerd** » Thu Aug 19, 2010 2:17 pm

It works with 2.6.36-rc1 released a couple of days ago.

tooler · Post by **tooler** » Wed Aug 25, 2010 2:12 pm

wuzzerd wrote:It works with 2.6.36-rc1 released a couple of days ago.

I can confirm e1000e works again for me with vanilla-sources 2.6.36-rc1.
(unfortunately nvidia-drivers are not ready for this kernel, so I'll have to wait for new version)

firephoto · Post by **firephoto** » Wed Aug 25, 2010 5:01 pm

I saw some changes for e1000e that are specific to e1000e chips (what i have) go into the kernel yesterday. They are up for .34 and .35 stable review.

http://marc.info/?l=linux-kernel&m=128269150907468&w=2

[085/114] e1000e: disable ASPM L1 on 82573

2.6.35-stable review patch. If anyone has any objections, please let us know.

------------------

From: Bruce Allan <...@intel.com>

commit 19833b5dffe2f2e92a1b377f9aae9d5f32239512 upstream.

On the e1000-devel mailing list, Nils Faerber reported latency issues with
the 82573 LOM on a ThinkPad X60. It was found to be caused by ASPM L1;
disabling it resolves the latency. The issue is present in kernels back
to 2.6.34 and possibly 2.6.33.

http://marc.info/?l=linux-kernel&m=128269131207207&w=2

[086/114] e1000e: dont check for alternate MAC addr on parts that dont support it

2.6.35-stable review patch. If anyone has any objections, please let us know.

------------------

commit 1aef70ef125165e0114a8e475636eff242a52030 upstream.

From: Bruce Allan <...@intel.com>

The alternate MAC address feature is only supported by 80003ES2LAN and
82571 LOMs as well as a couple 82571 mezzanine cards. Checking for an
alternate MAC address on other parts can fail leading to the driver not
able to load. This patch limits the check for an alternate MAC address
to be done only for parts that support the feature.

This issue has been around since support for the feature was introduced
to the e1000e driver in 2.6.34.

MageSlayer · Post by **MageSlayer** » Fri Oct 08, 2010 9:34 pm

Has anybody managed to make 2.6.35 work with e1000e driver?

I have 2.6.35.7 vanilla and upgrading dhcpcd to 5.2.7 did not help.
Those two patches referring from last message are in.

firephoto · Post by **firephoto** » Fri Oct 08, 2010 9:43 pm

I gave up and went to 2.6.36_rc and haven't had the issue. The changes I saw go into .36 didn't all make it to .35 that were related to these issues.

This is with an Intel 82566DC onboard nic.