Bug 165048

Summary: On system with only 802.1q vlans configured, first interface doesn't work
Product: [Fedora] Fedora Reporter: Allen Smith <lazlor>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: davej, pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 2.6.13-1.1526_FC4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-16 16:21:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1]
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 (2.6.13.2). 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!