Bug 227972 - 2.6.19-1.2898.2.3.fc7xen #1 SMP breaks networking
2.6.19-1.2898.2.3.fc7xen #1 SMP breaks networking
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Juan Quintela
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2007-02-09 02:40 EST by Naoki
Modified: 2009-12-14 15:39 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 21:09:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix bnx2 promisc mode (77.63 KB, patch)
2007-03-02 10:23 EST, Stephen Tweedie
no flags Details | Diff

  None (edit)
Description Naoki 2007-02-09 02:40:01 EST
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:

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:  Bcast:  Mask:
          inet6 addr: fe80::214:5eff:fede:92a4/64 Scope:Link
          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".
Comment 1 Naoki 2007-02-14 03:08:43 EST
Some more info :
# rpm -qa|grep xen
Comment 2 Christophe Saout 2007-02-25 18:23:03 EST
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.
Comment 3 Christophe Saout 2007-02-25 18:36:11 EST
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
Comment 4 Naoki 2007-02-25 23:45:33 EST
You are correct in your assumption that it's a dom0 network issue. peth0 is
available and has link according to ethtool.  
Comment 5 Stephen Tweedie 2007-03-02 10:21:39 EST
This is an upstream bnx2.c driver bug, fixed in 2.6.20.  I'll attach the patch.
Comment 6 Stephen Tweedie 2007-03-02 10:23:08 EST
Created attachment 149124 [details]
Fix bnx2 promisc mode

commit 7510873d8659f4192cb5b3327f748e401d216399
Author: Michael Chan <mchan@broadcom.com>
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@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
Comment 7 Bill Nottingham 2007-03-02 12:35:14 EST
Moving to 'devel' as discussed on
Comment 8 Red Hat Bugzilla 2007-07-24 21:37:57 EDT
change QA contact
Comment 9 Naoki 2007-07-24 21:43:48 EDT
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.
Comment 10 Bug Zapper 2008-04-03 15:04:10 EDT
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 11 Bug Zapper 2008-05-06 21:09:05 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.