1. 29 10月, 2013 1 次提交
    • J
      ixgbe: fix qv_lock_napi call in ixgbe_napi_disable_all · 27d9ce4f
      Jacob Keller 提交于
      ixgbe_napi_disable_all calls napi_disable on each queue, however the busy
      polling code introduced a local_bh_disable()d context around the napi_disable.
      The original author did not realize that napi_disable might sleep, which would
      cause a sleep while atomic BUG. In addition, on a single processor system, the
      ixgbe_qv_lock_napi loop shouldn't have to mdelay. This patch adds an
      ixgbe_qv_disable along with a new IXGBE_QV_STATE_DISABLED bit, which it uses to
      indicate to the poll and napi routines that the q_vector has been disabled. Now
      the ixgbe_napi_disable_all function will wait until all pending work has been
      finished and prevent any future work from being started.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com>
      Cc: Alexander Duyck <alexander.duyck@intel.com>
      Cc: Hyong-Youb Kim <hykim@myri.com>
      Cc: Amir Vadai <amirv@mellanox.com>
      Cc: Dmitry Kravkov <dmitry@broadcom.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      27d9ce4f
  2. 24 10月, 2013 2 次提交
  3. 02 10月, 2013 1 次提交
  4. 14 9月, 2013 1 次提交
  5. 13 9月, 2013 1 次提交
  6. 29 8月, 2013 3 次提交
  7. 02 8月, 2013 1 次提交
  8. 31 7月, 2013 7 次提交
  9. 11 7月, 2013 1 次提交
  10. 11 6月, 2013 2 次提交
  11. 26 4月, 2013 1 次提交
    • J
      ixgbe: fix EICR write in ixgbe_msix_other · d87d8307
      Jacob Keller 提交于
      Previously, the ixgbe_msix_other was writing the full 32bits of the set
      interrupts, instead of only the ones which the ixgbe_msix_other is
      handling. This resulted in a loss of performance when the X540's PPS feature is
      enabled due to sometimes clearing queue interrupts which resulted in the driver
      not getting the interrupt for cleaning the q_vector rings often enough. The fix
      is to simply mask the lower 16bits off so that this handler does not write them
      in the EICR, which causes them to remain high and be properly handled by the
      clean_rings interrupt routine as normal.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d87d8307
  12. 25 4月, 2013 4 次提交
  13. 20 4月, 2013 3 次提交
  14. 19 4月, 2013 3 次提交
    • J
      ixgbe: Remove unnecessary #ifdef CONFIG_DEBUG_FS tests · 33243fb0
      Joe Perches 提交于
      Add some empty static inlines instead to make
      the code more readable.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      33243fb0
    • J
      ixgbe: Add support for WoL on 82599 SFP+ LOM · 979fe5f7
      Jacob Keller 提交于
      This patch adds software support for WoL for the 82599 SFP+ LOM device,
      (ID 0x8976)
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      979fe5f7
    • A
      ixgbe: in shutdown, do netif_running() under rtnl_lock · 499ab5cc
      akepner 提交于
      During shutdown it's possible for __dev_close() (which holds
      rtnl_lock) to clear the __LINK_STATE_START bit, and for ixgbe
      to then read that bit (without holding rtnl_lock), and then
      not fail to free irqs, etc. The result is a crash like this:
      
      ------------[ cut here ]------------
      kernel BUG at drivers/pci/msi.c:313!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
      CPU 1
      Pid: 5910, comm: reboot Tainted: P           ----------------   2.6.32 #1 empty
      RIP: 0010:[<ffffffff81305c2b>]  [<ffffffff81305c2b>] free_msi_irqs+0x11b/0x130
      RSP: 0018:ffff880185c9bc88  EFLAGS: 00010282
      RAX: ffff880219f58bc0 RBX: ffff88021ac53b00 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000000004a
      RBP: ffff880185c9bcc8 R08: 0000000000000002 R09: 0000000000000106
      R10: 0000000000000000 R11: 0000000000000006 R12: ffff88021e524778
      R13: 0000000000000001 R14: ffff88021e524000 R15: 0000000000000000
      FS:  00007f90821b7700(0000) GS:ffff880028220000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f90818bd010 CR3: 0000000132c64000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process reboot (pid: 5910, threadinfo ffff880185c9a000, task ffff88021bf04a80)
      Stack:
       ffff880185c9bc98 000000018130529d ffff880185c9bcc8 ffff88021e524000
      <0> 0000000000000004 ffff88021948c700 0000000000000000 ffff880185c9bda7
      <0> ffff880185c9bce8 ffffffff81305cbd ffff880185c9bce8 ffff88021948c700
      Call Trace:
       [<ffffffff81305cbd>] pci_disable_msix+0x3d/0x50
       [<ffffffffa00501d5>] ixgbe_reset_interrupt_capability+0x65/0x90 [ixgbe]
       [<ffffffffa00512f6>] ixgbe_clear_interrupt_scheme+0xb6/0xd0 [ixgbe]
       [<ffffffffa005330b>] __ixgbe_shutdown+0x5b/0x200 [ixgbe]
       [<ffffffffa00534ca>] ixgbe_shutdown+0x1a/0x60 [ixgbe]
       [<ffffffff812f6c7c>] pci_device_shutdown+0x2c/0x50
       [<ffffffff813727fb>] device_shutdown+0x4b/0x160
       [<ffffffff8107d98c>] kernel_restart_prepare+0x2c/0x40
       ehci timer_action, mod_timer io_watchdog
       [<ffffffff8107d9e6>] kernel_restart+0x16/0x60
       [<ffffffff8107dbfd>] sys_reboot+0x1ad/0x200
       [<ffffffff811676cf>] ? __d_free+0x3f/0x60
       [<ffffffff81167748>] ? d_free+0x58/0x60
       [<ffffffff8116f7c0>] ? mntput_no_expire+0x30/0x100
       [<ffffffff81152b11>] ? __fput+0x191/0x200
       [<ffffffff816565fe>] ? do_page_fault+0x3e/0xa0
       [<ffffffff8100b132>] system_call_fastpath+0x16/0x1b
      Code: 4c 89 ef e8 98 8c e3 ff 4d 39 f4 48 8b 43 10 75 cf 48 83 c4 18 5b 41 5c
      41 5d 41 5e 41 5f c9 c3 49 8b 7d 20 e8 07 5a d3 ff eb c9 <0f> 0b 0f 1f 00 eb fb
      66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
       ehci timer_action, mod_timer io_watchdog
      RIP  [<ffffffff81305c2b>] free_msi_irqs+0x11b/0x130
       RSP <ffff880185c9bc88>
      ---[ end trace 27de882a0fe75593 ]---
      
      (This was seen on a pretty old kernel/driver, but looks like
      the same bug is still possible.)
      
      Signed-off-by: <akepner@riverbed.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      499ab5cc
  15. 18 4月, 2013 7 次提交
  16. 05 4月, 2013 1 次提交
  17. 08 3月, 2013 1 次提交