A set of 2 patches to fix this was accepted upstream:

https://github.com/torvalds/linux/commit/2b16f048729bf35e6c28a40cbfad07239f9dcd90
https://github.com/torvalds/linux/commit/8914a595110a6eca69a5e275b323f5d09e18f4f9

I will send an SRU shortly.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1715519

Title:
  bnx2x_attn_int_deasserted3:4323 MC assert!

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  (This bug provides a place to track the progress of this issue
  upstream and then in to Ubuntu.)

  A ppc64le system runs as a guest under PowerVM. This guest has a bnx2x
  card attached, and uses openvswitch to bridge an ibmveth interface for
  traffic from other LPARs.

  We see the following crash sometimes when running netperf:
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_attn_int_deasserted3:4323(enP24p1s0f2)]MC assert! 
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:720(enP24p1s0f2)]XSTORM_ASSERT_LIST_INDEX 0x2 
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:736(enP24p1s0f2)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 
0x25e42a7e 0x00462a38 0x00010052 
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:750(enP24p1s0f2)]Chip Revision: everest3, FW Version: 7_13_1 
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_attn_int_deasserted3:4329(enP24p1s0f2)]driver assert 
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_panic_dump:923(enP24p1s0f2)]begin crash dump ----------------- 
  ... (dump of registers follows) ...

  Subsequent debugging reveals that the packets causing the issue come
  through the ibmveth interface - from the AIX LPAR. The veth protocol
  is 'special' - communication between LPARs on the same chassis can use
  very large (64k) frames to reduce overhead. Normal networks cannot
  handle such large packets, so traditionally, the VIOS partition would
  signal to the AIX partitions that it was 'special', and AIX would send
  regular, ethernet-sized packets to VIOS, which VIOS would then send
  out.

  This signalling between VIOS and AIX is done in a way that is not
  standards-compliant, and so was never made part of Linux. Instead, the
  Linux driver has always understood large frames and passed them up the
  network stack.

  In some cases (e.g. with TCP), multiple TCP segments are coalesced
  into one large packet. In Linux, this goes through the generic receive
  offload code, using a similar mechanism to GSO. These segments can be
  very large which presents as a very large MSS (maximum segment size)
  or gso_size.

  Normally, the large packet is simply passed to whatever network
  application on Linux is going to consume it, and everything is OK.

  However, in this case, the packets go through Open vSwitch, and are
  then passed to the bnx2x driver. The bnx2x driver/hardware supports
  TSO and GSO, but with a restriction: the maximum segment size is
  limited to around 9700 bytes. Normally this is more than adequate as
  jumbo frames are limited to 9000 bytes. However, if a large packet
  with large (>9700 byte) TCP segments arrives through ibmveth, and is
  passed to bnx2x, the hardware will panic.

  Turning off TSO prevents the crash as the kernel resegments the data
  and assembles the packets in software. This has a performance cost.

  Clearly at the very least, bnx2x should not crash in this case.

  One patch to do this was sent upstream:
  https://www.spinics.net/lists/netdev/msg452932.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1715519/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to