#357 Intel 82546GB chip does not work with OpenVSwitch

closed
Tushar Dave
e1000 (137)
in-kernel_driver
1
2013-07-02
2012-09-10
T. Essigke
No

The 82546GB chip does not work with OpenVSwitch, while similar chips do. It works with the old vlan/bridge code. In the attachement is a script to reproduce the problem and the output of ethregs.

Here is a summary of the results:
vlan/bridge openvswitch
ping ethregs ping ethregs
80003ES2 + - + -
80003ES2_iomem + + + +
80003ES2_iomem_run2 + + + +
82546GB + + - +
82546GB_iomem + + - +
82546GB_iomem_run2 - + - +

Maybe it is an initialization issue of the card.

For more details see my mails on the e1000-devel mailing list.

1 Attachments

Discussion

  • for posterity: original email here:
    Dear e1000 developers,

    I use OpenVSwitch http://openvswitch.org/ on a number of servers. It
    replaces the bridge kernel module and does VLANs in a different way than
    the original kernel implementation. It is much more convenient and
    performs better when you have a virtualization servers where the VMs
    connect to different VLANs via bridges.

    It works fine with:
    Intel 80003ES2 dual port 1GBit on-board
    Intel 82599EB dual port 10GBit PCI-e Adapter X520-2
    Intel Pro/1000 PT Dual Port NIC (EXPI9402PT, probably 82571GB chip)
    Intel 82576 dual port 1GBit on-board and PCI-e
    Intel 82571EB dual port 1GBit
    Broadcom NetXtreme II BCM5708 dual port 1GBit on-board
    Broadcom NetXtreme BCM5704 dual port 1GBit on-board (PCI-X)
    and probably many other Chips...

    I have tried two Intel Pro/1000 MT Dual Port NIC (PWLA8492MT, 82546GB
    chip) which work fine when I configure them directly or with
    vlan/bridging as it is in the kernel for some time. However if I
    configure openvswitch, this card does not work while cards with other
    chips work fine in the same server.

    I removed all other PCI-X cards and tried different slots without success.
    I tried two different servers (Supermicro 64-bit and Fujitsu 32-bit)
    with same behavior.

    I may see traffic with tcpdump, but no packages appear to be send. In
    this case ARP requests are answered by the card/server, but never leave
    it. If I can see traffic or not seems not 100% reproducible (certainly I
    made sure that it works on the bare device).

    I assume it is a bug in the NIC driver or firmware of 82546GB chips.
    Which chip dependent code in the driver could cause such a behavior? I
    would like to test a patch!

    First, I asked on the openvswitch mailing list and they consider it as a
    driver problem.

    My system is:
    Ubuntu 12.04
    Supermicro: Kernel 3.2.0-29-generic, 64-bit
    Fujitsu: Kernel 3.2.0-29-generic-pae, 32-bit
    Openvswitch 1.4.0-1ubuntu1.2

     
  • more info provided here about the attachment
    Hi Jesse,

    thank you for picking up my problem!

    I made a script and ran it on my system. Attached is the script and the
    output. So it should be very easy for you to reproduce my problem.

    At the top of the script you need to make some adjustments for your
    network; the only command line argument is the interface name.

    I thought it makes sense to have the output of the working 80003ES2 NIC
    and the problematic 82546GB NIC for comparison. However, ethregs
    required booting with iomem=relaxed (_iomem) to work for the former. I
    realized that for the 82546GB chip it makes a difference if the
    openvswitch modules were loaded before or not. So I started all my runs
    with a cold-booted system with the openvswitch modules blacklisted. I
    demonstrate the effect of previously loaded openvswitch modules with the
    _run2 files which were generated by a second run of the script right
    after the first run.

    Here is a summary of the results:
    vlan/bridge openvswitch
    ping ethregs ping ethregs
    80003ES2 + - + -
    80003ES2_iomem + + + +
    80003ES2_iomem_run2 + + + +
    82546GB + + - +
    82546GB_iomem + + - +
    82546GB_iomem_run2 - + - +

    Maybe it is an initialization issue of the card.

    I hope you can understand the cause of the problem from the ethregs
    output included in the files.

    • labels: --> e1000
    • assigned_to: Jesse Brandeburg
     
  • I found why you don't see any transmits. CTRL.VME is not set (0x40000000) and needs to be for the hardware to insert the vlan tag on transmit. So your hardware is currently transmitting untagged frames when openvswitch enabled the vlan. This appears to be (unverified) because openvswitch is actively clearing the netdev->features flag NETIF_F_HW_VLAN_RX, and then doesn't read the features mask back afterward to find out that our e1000 hardware no longer supports tag insertion.

     
    • assigned_to: Jesse Brandeburg --> Tushar Dave
     
  • Tushar Dave
    Tushar Dave
    2012-11-27

    @T. Essigke:
    Please confirm that your e1000 driver has patch - e1000: fix vlan processing regression -commit 52f5509fe8ccb607ff9b84ad618f244262336475

    -Tushar

     
  • Tushar Dave
    Tushar Dave
    2012-12-18

    • status: open --> pending
     
  • Tushar Dave
    Tushar Dave
    2012-12-18

    Changing status to pending.
    This bug will auto close if you don't update within 60 days. You can certainly reopen it anytime.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-02

    • status: pending --> closed
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-02

    Closing manually, no auto-close.