You need to sign in or sign up before continuing.
  1. 26 5月, 2018 1 次提交
    • B
      ixgbe: Report PCIe link properties with pcie_print_link_status() · 4695ca9d
      Bjorn Helgaas 提交于
      Previously the driver used pcie_get_minimum_link() to warn when the NIC
      is in a slot that can't supply as much bandwidth as the NIC could use.
      
      pcie_get_minimum_link() can be misleading because it finds the slowest link
      and the narrowest link (which may be different links) without considering
      the total bandwidth of each link.  For a path with a 16 GT/s x1 link and a
      2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
      bandwidth, not the true available bandwidth of about 1969 MB/s for a
      16 GT/s x1 link.
      
      Use pcie_print_link_status() to report PCIe link speed and possible
      limitations instead of implementing this in the driver itself.  This finds
      the slowest link in the path to the device by computing the total bandwidth
      of each link and compares that with the capabilities of the device.
      
      The dmesg change is:
      
        - PCI Express bandwidth of %dGT/s available
        - (Speed:%s, Width: x%d, Encoding Loss:%s)
        + %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
      
      or, if the device is capable of better performance than is available in the
      current slot:
      
        - This is not sufficient for optimal performance of this card.
        - For optimal performance, at least %dGT/s of bandwidth is required.
        - A slot with more lanes and/or higher speed is suggested.
        + %u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)
      
      Note that the driver previously used dev_warn() to suggest using a
      different slot, but pcie_print_link_status() uses dev_info() because if the
      platform has no faster slot available, the user can't do anything about the
      warning and may not want to be bothered with it.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4695ca9d
  2. 24 3月, 2018 5 次提交
  3. 27 2月, 2018 2 次提交
  4. 27 1月, 2018 2 次提交
  5. 26 1月, 2018 1 次提交
  6. 24 1月, 2018 7 次提交
  7. 13 1月, 2018 8 次提交
  8. 10 1月, 2018 11 次提交
  9. 06 1月, 2018 1 次提交
  10. 07 12月, 2017 1 次提交
  11. 22 11月, 2017 1 次提交
    • B
      ixgbe: Fix skb list corruption on Power systems · 0a9a17e3
      Brian King 提交于
      This patch fixes an issue seen on Power systems with ixgbe which results
      in skb list corruption and an eventual kernel oops. The following is what
      was observed:
      
      CPU 1                                   CPU2
      ============================            ============================
      1: ixgbe_xmit_frame_ring                ixgbe_clean_tx_irq
      2:  first->skb = skb                     eop_desc = tx_buffer->next_to_watch
      3:  ixgbe_tx_map                         read_barrier_depends()
      4:   wmb                                 check adapter written status bit
      5:   first->next_to_watch = tx_desc      napi_consume_skb(tx_buffer->skb ..);
      6:   writel(i, tx_ring->tail);
      
      The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not
      get loaded prior to tx_buffer->next_to_watch, which then results in loading
      a stale skb pointer. This patch replaces the read_barrier_depends with
      smp_rmb to ensure loads are ordered with respect to the load of
      tx_buffer->next_to_watch.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0a9a17e3