1. 05 10月, 2015 1 次提交
  2. 19 8月, 2015 1 次提交
    • S
      igb: Fix oops caused by missing queue pairing · 72ddef05
      Shota Suzuki 提交于
      When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
      set if adapter->rss_queues exceeds half of max_rss_queues in
      igb_init_queue_configuration().
      On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
      queues exceeds half of max_combined in igb_set_channels() when changing
      the number of queues by "ethtool -L".
      In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
      of adapter->msix_entries[], an overflow can occur in
      igb_set_interrupt_capability(), which in turn leads to an oops.
      
      Fix this problem as follows:
       - When changing the number of queues by "ethtool -L", set
         IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
       - When increasing the size of q_vector, reallocate it appropriately.
         (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
      
      Another possible way to fix this problem is to cap the queues at its
      initial number, which is the number of the initial online cpus. But this
      is not the optimal way because we cannot increase queues when another
      cpu becomes online.
      
      Note that before commit cd14ef54 ("igb: Change to use statically
      allocated array for MSIx entries"), this problem did not cause oops
      but just made the number of queues become 1 because of entering msi_only
      mode in igb_set_interrupt_capability().
      
      Fixes: 907b7835 ("igb: Add ethtool support to configure number of channels")
      CC: stable <stable@vger.kernel.org>
      Signed-off-by: NShota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      72ddef05
  3. 23 1月, 2015 1 次提交
  4. 31 12月, 2014 1 次提交
  5. 02 10月, 2014 1 次提交
    • B
      igb: remove blocking phy read from inside spinlock · 7acf6318
      Bernhard Kaindl 提交于
      Remove a source of latency spikes (in my case up to 10ms) by not calling
      code that uses mdelay() for feeding a phy statistic (rx errors for idle
      symbols - not data -> idle_errors) while being called with a spinlock held.
      
      As idle_errors isn't read, this patch only removes unused code and data.
      
      Later, more complicated changes may be applied to address the spinlock and
      allow for some PHY diagnostics by harvesting this PHY stats register fully.
      
      This patch is designed to fix the issue and be safe for longterm/stable.
      
      For the Intel e1000e driver, the same change was applied in 2008 with
      commit 23033fad ("e1000e: remove phy read from inside spinlock").
      
      The mdelay is triggered by HW/SW semaphores, thus it depends on the HW.
      
      I've HW that triggers it even when idle. Others may trigger it only e.g.
      when Ethernet ports aquire or loose the link or on ifconfig up / down.
      We've noticed this first from delays in frame rx/tx due to the mdelay().
      
      Example command for checking if the issue is triggered: cyclictest -Smp1
      (Look for occasional "Max:" values > 4000 or use -b 4000 to stop if greater)
      
      It was observed with I350 ports connected to other I350 ports, but not
      if driver and EEPROM was modified to run the I350 in EEPROM-less mode.
      
      phy_stats.idle_errors and .receive_errors (isn't touched) occupy 64 not
      used bits in the adapter struct: Their allocation may be removed as well.
      
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Todd Fujinaka <todd.fujinaka@intel.com>
      Fixes: 12dcd86b ("igb: fix stats handling") (this added the spin_lock)
      Signed-off-by: NBernhard Kaindl <bk-linux@use.startmail.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7acf6318
  6. 25 4月, 2014 1 次提交
  7. 23 4月, 2014 1 次提交
  8. 11 4月, 2014 1 次提交
  9. 28 3月, 2014 1 次提交
  10. 21 3月, 2014 1 次提交
  11. 13 3月, 2014 1 次提交
  12. 27 2月, 2014 2 次提交
  13. 18 12月, 2013 1 次提交
  14. 10 12月, 2013 3 次提交
  15. 02 10月, 2013 1 次提交
  16. 25 9月, 2013 1 次提交
    • J
      intel: Remove extern from function prototypes · 5ccc921a
      Joe Perches 提交于
      There are a mix of function prototypes with and without extern
      in the kernel sources.  Standardize on not using extern for
      function prototypes.
      
      Function prototypes don't need to be written with extern.
      extern is assumed by the compiler.  Its use is as unnecessary as
      using auto to declare automatic/local variables in a block.
      Signed-off-by: NJoe Perches <joe@perches.com>
      5ccc921a
  17. 04 9月, 2013 1 次提交
  18. 22 8月, 2013 2 次提交
  19. 21 5月, 2013 2 次提交
  20. 19 4月, 2013 5 次提交
  21. 05 3月, 2013 1 次提交
  22. 15 2月, 2013 2 次提交
  23. 19 1月, 2013 1 次提交
  24. 18 1月, 2013 4 次提交
  25. 01 12月, 2012 1 次提交
  26. 22 11月, 2012 1 次提交
  27. 14 11月, 2012 1 次提交