Description of problem: When xend, starts my eth0 interface becomes inoperable. When booting with a non-xen enabled kernel, or a xen-enabled kernel with xend disabled, my eth0 starts and DHCPs without incident. As soon as Xend is started, the bridges are created, and my eth0 stops functioning. Version-Release number of selected component (if applicable): kernel-xen-2.6.18-1.2798.fc6 x86_64 xen-3.0.3-0.1.rc3 How reproducible: Every time. Steps to Reproduce: 1.Boot a xen-enabled kernel with xend running 2.try to use your network connection Actual results: Cannot connect anywhere Expected results: To be able to go somewhere Additional info: This is a Dell Poweredge 1950.
Tested on same phyical host under the i386 version and I find the same problem occurs. I can provide anything you need to help debug this problem
Please give us some basic information about your network config. Without that we cannot help at all; networking is working fine under -xen on multiple test boxes for me. Thanks!
I honestly have no idea what to tell you or what you'd like to see. I'm connected on eth0 to my network(Eth0 uses the bnx2 module) and if the Xen daemon is off, I can DHCP and everything works fine. I get an IP. I can ping. Everything works. If I start the xen daemon, evertything stops working. I lose my IP address on eth0. I see no traffic on eth0 via tcpdump. If I turn off the xend service and down/up the interfaces, things do not return to normal. No other interfaces work either. I've even tried plugging in a USB NIC to see if it was a driver problem with the built-in NICs and it doesn't work either. IPtables and selinux are both off. Let me know specifically what would help and I'll get it to you. I can give you access to the host if you'd like as well.
Some general info about your networking configuration. To start with the output from the follows commands would be useful: ifconfig -a route -n sysctl -a iptables -L -n -a If you can get this info before and after strarting the xend service, that'd be even better.
Created attachment 139874 [details] requested information about problem
Created attachment 140102 [details] ifconfig -a
Created attachment 140103 [details] route -n (IPv4)
Created attachment 140104 [details] route -A inet6 -n (IPv6)
Created attachment 140105 [details] sysctl -a
Networking problems under Xen are not only 64-bit related, because on my Pentium 4 (i686) workstation I also have networking troubles. My workstation is configured for DHCP, and IPv4 works as expected. But IPv6 is broken. I get a Link local address, and a Global IPv6 address (of course, both of them work). But I cannot get anywhere outside of my box with IPv6, even not to other IPv6 machines on the same network. Tested with ping (ICMP) and ssh (TCP). With the old-school non-Xen kernel (i686), everything is fine. (sorry, I better should have archived the attachments into one file)
This problem is not fixed by the kernel-2.6.18-1.2849 xen kernel.
This is the same issue as #204534 which is on its way to being resolved.
Super! Except that noone can see that bug. Is it possible to get a short description what the problem is? Kernel? Xen? Somewhere in between? Thanks
It's a core kernel bnx2 driver firmware bug that is triggered by Xen's bridging setup.
FYI I have identical behaviour to the submitter on an Opteron system with Tigon network interfaces (Tigon3 [partno BCM95721], Rev 401, PHY(5750), PCI Express 10/100/1000Base T).
Created attachment 144248 [details] [BNX2]: Fix Xen problem. This patch will appear in 2.6.20. [BNX2]: Fix Xen problem. This fixes the problem of not receiving packets in the Xen bridging environment. The Xen script sets the device's MAC address to FE:FF:FF:FF:FF:FF and puts the device in promiscuous mode. The firmware had problem receiving all packets in this configuration. New firmware and setting the PROM_VLAN bit when in promiscuous mode will fix this problem. Signed-off-by: Michael Chan <mchan> Signed-off-by: David S. Miller <davem>
The rawhide kernel now has 2.6.20-rc1 which contains the fix.
*** Bug 220454 has been marked as a duplicate of this bug. ***