# DHCPcd problem with latest kernel (vanilla)

## abrown118321

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.Last edited by abrown118321 on Mon Aug 02, 2010 9:14 pm; edited 1 time in total

----------

## Etal

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

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

Here's what I get for Linux 2.6.34.1:

```
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:

```
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")

----------

## asturm

same issue with my e1000e wired ethernet connection since 2.6.35

----------

## Etal

Here's my card:

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

----------

## idella4

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.

```

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

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"

```
[    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

Looks like it might be a bug in dhcpcd:

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

----------

## mpagano

I think we just might need a version bump.

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

 *Quote:*   

> * 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

That fixed it for me   :Smile: 

----------

## asturm

you beat me to it   :Very Happy: 

----------

## MaDDeePee

Thanks a lot!  :Smile: 

----------

## firephoto

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

 *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

 *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

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

 *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

 *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?
> ...

 

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:

```

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):

```

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

 *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

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

----------

## tooler

 *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

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

 *Quote:*   

> 
> 
> [085/114] e1000e: disable ASPM L1 on 82573
> 
> 2.6.35-stable review patch.  If anyone has any objections, please let us know.
> ...

 

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

 *Quote:*   

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

 

----------

## MageSlayer

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

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.

----------

## MageSlayer

 *firephoto wrote:*   

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

 

Yeap. Same story - Intel Corporation 82566DM, it works under 2.6.36_rc7

Thanks

----------

