Description of problem: Devices can DHCP on boot, routes are correctly set. But no network traffic is passing. tcpdump on eth0 shows zero packets, even when pinging local IP. The eth0 interface seems to have something quite strange happening, mii-tool reports an error on the interface, and ethtool simply states : "Settings for eth0: Link detected: yes" How reproducible: Always. Additional info: 2.6.20-1.2922.fc7 #1 SMP - Networking works fine. This is with the "bnx2" driver. [root@localhost ~]# cat /etc/modprobe.conf alias eth0 bnx2 alias eth1 bnx2 [root@localhost ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:14:5E:DE:92:A4 inet addr:10.0.14.55 Bcast:10.0.255.255 Mask:255.255.0.0 inet6 addr: fe80::214:5eff:fede:92a4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:356807 errors:0 dropped:0 overruns:0 frame:0 TX packets:86 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:63701071 (60.7 MiB) TX bytes:12099 (11.8 KiB) lsmod is indentical under "2.6.19-1.2898.2.3.fc7xen" & "2.6.20-1.2922.fc7 #1 SMP".
Some more info : # rpm -qa|grep xen xen-libs-3.0.4-6.fc7 xen-3.0.4-6.fc7 kernel-xen-2.6.19-1.2898.2.3.fc7
Are you seeing messages like this in the guest kernel log? (one message for every packet to be received, the send path guest -> dom0 works fine) Feb 25 23:56:54 <hostname> netfront: rx->offset: 12, size: 4294967295 This happens here on amd64 if I use the 2.6.19-1.2898.2.3.fc7xen for Dom0 An older Dom0 (kernel-2.6.18-1.2869.fc6) works fine (with 2.6.19...-xen guests, all on top of 3.0.4-1 hypervisor as well) In all cases the guests use the copying receive path.
Sorry, I take part of it back. With the older Dom0, the 2.6.19/3.0.4 guests yield: netfront: device eth0 has flipping receive path. So I don't know whether this is a Dom0 or DomU problem. And anyway, the problem reported smells like a Dom0-only networking problem and might not be related. And, @naoki: Check if you have a "peth0" device. If you do, this is your real network card which has been renamed by Xen (eth0 is then a loopback attached to xenbr0).
You are correct in your assumption that it's a dom0 network issue. peth0 is available and has link according to ethtool.
This is an upstream bnx2.c driver bug, fixed in 2.6.20. I'll attach the patch.
Created attachment 149124 [details] Fix bnx2 promisc mode commit 7510873d8659f4192cb5b3327f748e401d216399 Author: Michael Chan <mchan> Date: Sun Nov 19 14:06:40 2006 -0800 [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>
Moving to 'devel' as discussed on https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00095.html.
change QA contact
I do not have this issue under 2.6.21, or 2.6.22 kernels. The problem does not occur in Fedora 7. I'm happy to close.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp