I noticed when I loaded the Livecd 2008.1 for the first time I took 'longer than normal' to get an IP from my router. After installing the base system, genkernel image and grub settings I rebooted and noticed the exact same delayed behavior in my clean Gentoo Enviroment. I've never submitted a bug before nor do I know exactly what's causing the bug but this is what I have observed. packages involved in my testing: sys-kernel/genkernel-3.4.10-r1 sys-kernel/gentoo-sources-2.6.25-r7 sys-apps/iproute2-2.2.22.20070710 net-misc/dhcpcd-3.2.3 net-misc/dhcp-3.1.1 net-misc/pump-0.8.24 Network module for my nic: r8169 After installing Gentoo on my system I immediately noticed an error when the boot process switched from runlevel boot to runlevel 3. As net.eth0 attempted to start { using only config_eth0=( "dhcp" ) in /etc/conf.d/net } all seems fine until the line 'dhcpcd'. The system hung for about 20 seconds then spit out these two lines; err, eth0: timed out warn, eth0: using IPV4LL address 169.254.xxx.xxx (the last two octets changed every boot obviously) After the error the system continued normally to the login prompt. I logged in as root and tried to ping my gateway (192.168.1.1) google.com and the ip of the interface. Only the ip of the interface responded (not even on the same subnet at this point I know but a test is a test). I configured a static IP for the interface in /etc/conf.d/net as; config_eth0=( "192.168.1.11/24 brd 192.168.1.255" ) routes_eth0=( "default via 192.168.1.1" ) and cycled the interface via ./net-eth0 restart. Exact same ping results from before, only the ip on eth0 returned a response, however I did notice something I didn't expect at this point. I typed ifconfig eth0 down and pinged the ip I statically set to the device and got a response. How do you get a response from an interface that is down? Shouldn't it be destination unreachable? Maybe it's nothing I could be a noob who knows, anyway. Not having any luck with a static ip I changed my net config back to eth0=( "dhcp" ) and cycled again with ./net-eth0 restart. I got the exact same error as I did on boot (different arp ip) but this time I just waited to see if it was just delayed like it was on the livecd. low and behold after exactly 1m40s I got this message in dmesg: NETDEV WATCHDOG: eth0: transmit timed out eth0 up a quick check of ifconfig confirmed that the interface now had an IP from the router and all pings were successful. I played with the /etc/conf.d/net file as much as possible to find a work around but no such luck. Changing the default ifconfig module to iproute2 had no change on the time it took for dhcpcd to pull an IP. I also tried different dhcp clients however dhclient and pump both failed on startup and eth0 never came up. dhcpcd was the only client that seemed to be able to fix itself. Thinking I had screwed the install up I booted off the livecd and observed how the internet came up and exactly like from the genkernel install the livecd could not get internet access until the error: NETDEV WATCHDOG: eth0: transmit timed out eth0 up appeared in dmesg. The timing of the message was slightly different when booting on the installcd ~1m30s from login. I have since compiled my own kernel using the same source, r8169, and I have no problems with static or dhcp configs -or- dhcp clients for that matter. As I said before I've never submitted a bug before and I've given as much information as I can and what I did to test and recreate so I'm skipping most of the rest of this form. Reproducible: Always Steps to Reproduce: use dhclient or pump on a genkernel install of gentoo and you will not be able to get internet. Actual Results: any client other than dhcpcd produced an error and prevented eth0 from going up Expected Results: dhclient and pump should be able to retrieve an IP from the router. please read description, I've said as much as I could.
Try a different network card in your system, so that we can rule out r8169 being the source of the trouble.
(In reply to comment #1) > Try a different network card in your system, so that we can rule out r8169 > being the source of the trouble. > Sadly in an effort to be eco-friedly (my gf was tired of looking at it) I recently recycled my 'spare parts box' so I don't have any pci nic cards anymore. I've never had trouble with the gigE onboard controllers that have come with my newer mobo's so I didn't see a need to keep it. And installing gentoo on the other two pc's isn't an option atm.
I fail to see what this has to do with genkernel.
Correct. It seems more like a kernel issue, as genkernel doesn't touch any of this stuff. About the only thing genkernel-specific that it could be would be a CONFIG_* option. Can you attach your working .config to this bug report?
Kernels previous to 2.6.27 had "issues" with the r8169 driver. I think we can just write it off to that. Regardless, it's not gk's fault.
