1. 14 Jun, 2016 8 commits
  2. 10 Jun, 2016 3 commits
  3. 07 Jun, 2016 3 commits
  4. 06 Jun, 2016 1 commit
    • Michal Schmidt's avatar
      bnx2x: allow adding VLANs while interface is down · a02cc9d3
      Michal Schmidt authored
      Since implementing VLAN filtering in commit 05cc5a39
      
      
      ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while
      the interface is down:
      
        # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10
        RTNETLINK answers: Bad address
      
      and in dmesg (with bnx2x.debug=0x20):
        bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN
        configuration the interface is down
      
      Other drivers have no problem with this.
      Fix this peculiar behavior in the following way:
       - Accept requests to add/kill VID regardless of the device state.
         Maintain the requested list of VIDs in the bp->vlan_reg list.
       - If the device is up, try to configure the VID list into the hardware.
         If we run out of VLAN credits or encounter a failure configuring an
         entry, fall back to accepting all VLANs.
         If we successfully configure all entries from the list, turn the
         fallback off.
       - Use the same code for reconfiguring VLANs during NIC load.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Acked-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a02cc9d3
  5. 31 May, 2016 1 commit
  6. 20 May, 2016 1 commit
  7. 15 May, 2016 9 commits
  8. 12 May, 2016 2 commits
    • Michael Chan's avatar
      bnxt_en: Add workaround to detect bad opaque in rx completion (part 2) · fa7e2812
      Michael Chan authored
      
      
      Add detection and recovery code when the hardware returned opaque value
      does not match the expected consumer index.  Once the issue is detected,
      we skip the processing of all RX and LRO/GRO packets.  These completion
      entries are discarded without sending the SKB to the stack and without
      producing new buffers.  The function will be reset from a workqueue.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa7e2812
    • Michael Chan's avatar
      bnxt_en: Add workaround to detect bad opaque in rx completion (part 1) · 376a5b86
      Michael Chan authored
      
      
      There is a rare hardware bug that can cause a bad opaque value in the RX
      or TPA completion.  When this happens, the hardware may have used the
      same buffer twice for 2 rx packets.  In addition, the driver will also
      crash later using the bad opaque as the index into the ring.
      
      The rx opaque value is predictable and is always monotonically increasing.
      The workaround is to keep track of the expected next opaque value and
      compare it with the one returned by hardware during RX and TPA start
      completions.  If they miscompare, we will not process any more RX and
      TPA completions and exit NAPI.  We will then schedule a workqueue to
      reset the function.
      
      This patch adds the logic to keep track of the next rx consumer index.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      376a5b86
  9. 06 May, 2016 1 commit
    • Jon Maxwell's avatar
      cnic: call cp->stop_hw() in cnic_start_hw() on allocation failure · f37bd0cc
      Jon Maxwell authored
      We recently had a system crash in the cnic module. Vmcore analysis confirmed
      that "ip link up" was executed which failed due to an allocation failure
      because of memory fragmentation. Futher analysis revealed that the cnic irq
      vector was still allocated after the "ip link up" that failed. When
      "ip link down" was executed it called free_msi_irqs() which crashed the system
      because the cnic irq was still inuse.
      
      PANIC: "kernel BUG at drivers/pci/msi.c:411!"
      
      The code execution was:
      
      cnic_netdev_event()
      if (event == NETDEV_UP) {
      .
      .
             ▹       if (!cnic_start_hw(dev))
      cnic_start_hw()
      calls cnic_cm_open() which failed with -ENOMEM
      cnic_start_hw() then took the err1 path:
      
      err1:
             cp->free_resc(dev); <---- frees resources but not irq vector
             pci_dev_put(dev->pcidev);
             return err;
      }
      
      
      
      This returns control back to cnic_netdev_event() but now the cnic irq vector
      is still allocated even although cnic_cm_open() failed. The next
      "ip link down" while trigger the crash.
      
      The cnic_start_hw() routine is not handling the allocation failure correctly.
      Fix this by checking whether CNIC_DRV_STATE_HANDLES_IRQ flag is set indicating
      that the hardware has been started in cnic_start_hw(). If it has then call
      cp->stop_hw() which frees the cnic irq vector and cnic resources. Otherwise
      just maintain the previous behaviour and free cnic resources.
      
      I reproduced this by injecting an ENOMEM error into cnic_cm_alloc_mem()s return
      code.
      
      # ip link set dev enpX down
      # ip link set dev enpX up <--- hit's allocation failure
      # ip link set dev enpX down <--- crashes here
      
      With this patch I confirmed there was no crash in the reproducer.
      Signed-off-by: default avatarJon Maxwell <jmaxwell37@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f37bd0cc
  10. 04 May, 2016 4 commits
  11. 28 Apr, 2016 1 commit
  12. 27 Apr, 2016 3 commits
  13. 21 Apr, 2016 2 commits
  14. 17 Apr, 2016 1 commit