Summary: | VLANs do not work without manual intervention | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | oninoshiko |
Component: | [OLD] baselayout | Assignee: | Daniel Drake (RETIRED) <dsd> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | kernel, uberlord |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=f4637b55ba960d9987a836617271659e9b7b0de8;hp=ab611487d8ada506e511d2b8f22fb8e7be9939b9 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
oninoshiko
2005-07-18 21:13:45 UTC
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 |