|Summary:||On system with only 802.1q vlans configured, first interface doesn't work|
|Product:||[Fedora] Fedora||Reporter:||Allen Smith <lazlor>|
|Component:||kernel||Assignee:||Dave Jones <davej>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Version:||4||CC:||davej, pfrields, wtogami|
|Fixed In Version:||2.6.13-1.1526_FC4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-16 16:21:12 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Allen Smith 2005-08-03 20:41:19 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: I am setting up a router that will have no untagged ethernet interfaces. Every interface is of the form eth0.x where x is 2-16 or so. The first vlan that I have configured (eth0.2) does not function if eth0 is configured not to come up at boot time. By not functioning I mean that if I 'tcpdump -n -i eth0.2' I see network traffic, but the system never responds to arps. If eth0 is configured to come up at boot time with an IP address, then this vlan works fine. Version-Release number of selected component (if applicable): vconfig-1.8 How reproducible: Always Steps to Reproduce: You'll need three vlans, two tagged and one untagged (regular ethernet). I used eth0, eth0.2 and eth0.8 1. Configure a system with eth0 to come up on boot 2. Configure vlans on eth0.2 and eth0.8 to come up at boot 3. Try and ping a host on vlan eth0.8 (this should work) 4. Try and ping a host on vlan eth0.2 (this should work) 5. reconfigure eth0 to not come up on boot 6. reboot and retry steps 3 and 4. 3 will succeed. 4 will fail Actual Results: No response from remote host Expected Results: There should have been a response from the remote host. Additional info: I realize this could be the kernel, ethernet driver or vconfig. This system is using the tg3 driver. I have the following ethernet card: tg3.c:v3.31 (June 8, 2005) PCI: Found IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:01:00.0 eth0: Tigon3 [partno(P6AB8) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:10:18:0b:f2:b8 eth0: RXcsums LinkChgREG MIirq ASF Split WireSpeed TSOcap eth0: dma_rwctrl[763f0000]
Comment 1 Allen Smith 2005-08-03 23:18:02 UTC
I can actually only make the first vlan work if the main interface is set to dhcp. If I set it to static then the first vlan doesn't work. Whacky. I just tried the bcm5700 driver and that works fine. I'll just pin the kernel and use that for now. -Allen
Comment 2 Phil Knirsch 2005-08-15 15:57:24 UTC
Might be related to some of the other vconfig bugs: If the interface is down vconfig can't set up the vlan. Although that doesn't explain why it works for 1 vlan then and not for the other... Maybe it's really a driver/kernel related problem here... Read ya, Phil
Comment 3 Allen Smith 2005-08-15 16:20:36 UTC
I'd believe it is a kernel or driver bug since the bcm5700 driver seems to work fine with everything else being the same. Should I open a bug against the driver?
Comment 4 Phil Knirsch 2005-08-15 16:22:58 UTC
I'll just reassign this bug to kernel, so they can see the tests which have been already done. Thanks for all the testing btw :) Read ya, Phil
Comment 5 Dave Jones 2005-09-30 07:11:51 UTC
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (18.104.22.168). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
Comment 6 Dave Jones 2005-11-10 20:20:43 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Comment 7 Dave Jones 2006-02-03 07:21:59 UTC
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Comment 8 Allen Smith 2006-02-16 16:21:12 UTC
This bug appears to have been fixed in a later kernel. Thanks!