this is on a IBM Blade HS20 model 8832 I am on baselayout 1.11.12-r4 vconfig 1.8 my /etc/conf.d/net looks like ifconfig_eth0=( "0.0.0.0" ) vlans_eth0="2 10" vconfig_eth0=( "set_name_type DEV_PLUS_VID_NO_PAD" ) ifconfig_eth0_2=( "xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy brodcast zz.zzz.zzz.zzz" ) ifconfig_eth0_10=( ""xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy brodcast zzz.zzz.zzz.zzz" ) routes_eth0_2=( "default gw ggg.ggg.ggg.ggg" ) when i run /etc/init.d/net.eth0 it acts as if it has broght everything up, and looking at ifconfig and route everything looks normal. but i have no local network connectivity until i down and up eth0. I did not have this problem a couple months ago, when I last added a machine (which used a different format for /etc/conf.d/net). I THINK it could be a bug with the new version of /etc/init.d/net.eth0.
If it looks ok then it probably is and maybe related to a kernel/driver/vlan bug. You misspelled the word "broadcast" btw - that may be the cause. Also, how did you bring eth0 down and then up? ifconfig? /etc/init.d/net.eth0 restart?
Looks to be related to this kernel bug, fixed in 2.6.13. I will rebuild my kernel to test this. If this is the case maybe we could add a delay as a workaround until everyone moves beyond 2.6.12. (http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.13-rc3) commit f4637b55ba960d9987a836617271659e9b7b0de8 Author: Tommy Christensen <tommy.christensen@tpack.net> Date: Tue Jul 12 12:13:49 2005 -0700 [VLAN]: Fix early vlan adding leads to not functional device OK, I can see what's happening here. eth0 doesn't detect link-up until after a few seconds, so when the vlan interface is opened immediately after eth0 has been opened, it inherits the link-down state. Subsequently the vlan interface is never properly activated and are thus unable to transmit any packets. dev->state bits are not supposed to be manipulated directly. Something similar is probably needed for the netif_device_present() bit, although I don't know how this is meant to work for a virtual device. Signed-off-by: David S. Miller <davem@davemloft.net>
I'd rather get the kernel fixed than fudge baselayout to delay for a specific kernel version. And would the length of the delay required depend on the speed of the box?
If the 2.6.13 fix solves the problem then we'll happily include it in 2.6.12. Does that patch solve the problem?
sorry for the delay, i needed some sleep -_- "unstable" vanilla-sources fixes this for me. (2.6.13-rc3)
Fixed in gentoo-sources-2.6.12-r7 Fixed in genpatches-2.6.12-11
