With 2.6.16-r13 network works fine. After upgrading to 2.6.17-r5 with genkernel 3.4.0-r1 network is down and all connected services don't start properly. NIC is a realtek-PCI. Attachements show system with working NIC/kernel 2.6.16-r13 (filenames ...WORK.txt) and without.
Created attachment 93982 [details] emerge --info WORK
Created attachment 93983 [details] lsmod WORK
Created attachment 93984 [details] lspci WORK
Created attachment 93985 [details] emerge --info without NIC
Created attachment 93986 [details] lsmod without NIC
Created attachment 93987 [details] lspci without NIC
Please attach dmesg output from both kernels
Strangely I booted the system with Kernel 2.6.17-r5 now - the NIC seems to come up with a delay .... after 10 minutes waiting it's up. I'll attach dmesg of the other kernel as well.
Created attachment 94211 [details] dmesg - 2.6.17-r5 NIC is coming up with a delay. During system startup NIC doesn't work.
After further digging and comparing the dmesg-outputs. The problem seems to be my NIC-config. The built-in card (VIA Rhine II) is refered to as eth0, while the PCI realtek is eth1 - therefore I get: dmesg | grep eth: eth0: VIA Rhine II at 0xec800000, 00:0c:6e:e2:67:ee, IRQ 177. eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1. eth1: RealTek RTL8139 at 0xe0f12000, 00:c0:26:25:7f:20, IRQ 193 eth1: Identified 8139 chip type 'RTL-8100B/8139D' eth0: link down My /etc/conf.d/net contains: config_eth0=( "192.168.100.44 netmask 255.255.255.0 broadcast 192.168.100.255" ) routes_eth0=("default via 192.168.100.1") I just wonder how my system worked the other weeks with the cable plugged in into eth1, but eth0 was up'n'running. Due the fact that it's not a kernel issue but seems to be a config thing this bug could be closed. I just use the other NIC (eth0) now, which works with all kernels.
In contrast to yesterday I booted the machine to discover that networks wasn't working - there seems to be a non-deterministic thing with labeling/discovering the network cards. Today the NIC-order was: eth0: RealTek RTL8139 at 0xe0c10000, 00:c0:26:25:7f:20, IRQ 177 eth0: Identified 8139 chip type 'RTL-8100B/8139D' 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004) via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 23 (level, low) -> IRQ 185 eth1: VIA Rhine II at 0xec800000, 00:0c:6e:e2:67:ee, IRQ 185. eth1: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1. Yesterday the other way round: eth0: VIA Rhine II at 0xec800000, 00:0c:6e:e2:67:ee, IRQ 177. eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1. eth1: RealTek RTL8139 at 0xe0f12000, 00:c0:26:25:7f:20, IRQ 193 eth1: Identified 8139 chip type 'RTL-8100B/8139D' eth0: link down So things seem to be related to the order of NIC-discovery.
Created attachment 94301 [details] dmesg 2.6.17-r5 normal bootup without changing network cables This dmesg shows the order of network cards beeing discovered
Created attachment 94302 [details] 2.6.17-r5 after changing the physical network cable to show NIC is up Same machine, after I put the network cable into the other NIC (just to show it's working physically.
Created attachment 94303 [details] emerge --info (today's version) To determine changes between first bug report and today's reopening of the bug.
With Linux gentoo 2.6.17-gentoo-r6 #1 SMP Fri Aug 25 14:45:24 CEST 2006 i686 AMD Athlon(TM) XP 2100+ AuthenticAMD GNU/Linux I didn't experience anything of the NIC problems so far.
