1. 23 8月, 2014 3 次提交
  2. 25 7月, 2014 1 次提交
    • D
      bnx2x: fix crash during TSO tunneling · fe26566d
      Dmitry Kravkov 提交于
      When TSO packet is transmitted additional BD w/o mapping is used
      to describe the packed. The BD needs special handling in tx
      completion.
      
      kernel: Call Trace:
      kernel: <IRQ>  [<ffffffff815e19ba>] dump_stack+0x19/0x1b
      kernel: [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
      kernel: [<ffffffff8105df5c>] warn_slowpath_fmt+0x5c/0x80
      kernel: [<ffffffff814a8c0d>] ? find_iova+0x4d/0x90
      kernel: [<ffffffff814ab0e2>] intel_unmap_page.part.36+0x142/0x160
      kernel: [<ffffffff814ad0e6>] intel_unmap_page+0x26/0x30
      kernel: [<ffffffffa01f55d7>] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]
      kernel: [<ffffffffa01f8dac>] bnx2x_tx_int+0xac/0x220 [bnx2x]
      kernel: [<ffffffff8101a0d9>] ? read_tsc+0x9/0x20
      kernel: [<ffffffffa01f8fdb>] bnx2x_poll+0xbb/0x3c0 [bnx2x]
      kernel: [<ffffffff814d041a>] net_rx_action+0x15a/0x250
      kernel: [<ffffffff81067047>] __do_softirq+0xf7/0x290
      kernel: [<ffffffff815f3a5c>] call_softirq+0x1c/0x30
      kernel: [<ffffffff81014d25>] do_softirq+0x55/0x90
      kernel: [<ffffffff810673e5>] irq_exit+0x115/0x120
      kernel: [<ffffffff815f4358>] do_IRQ+0x58/0xf0
      kernel: [<ffffffff815e94ad>] common_interrupt+0x6d/0x6d
      kernel: <EOI>  [<ffffffff810bbff7>] ? clockevents_notify+0x127/0x140
      kernel: [<ffffffff814834df>] ? cpuidle_enter_state+0x4f/0xc0
      kernel: [<ffffffff81483615>] cpuidle_idle_call+0xc5/0x200
      kernel: [<ffffffff8101bc7e>] arch_cpu_idle+0xe/0x30
      kernel: [<ffffffff810b4725>] cpu_startup_entry+0xf5/0x290
      kernel: [<ffffffff815cfee1>] start_secondary+0x265/0x27b
      kernel: ---[ end trace 11aa7726f18d7e80 ]---
      
      Fixes: a848ade4 ("bnx2x: add CSUM and TSO support for encapsulation protocols")
      Reported-by: NYulong Pei <ypei@redhat.com>
      Cc: Michal Schmidt <mschmidt@redhat.com>
      Signed-off-by: NDmitry Kravkov <Dmitry.Kravkov@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe26566d
  3. 02 7月, 2014 2 次提交
  4. 31 5月, 2014 1 次提交
  5. 26 3月, 2014 3 次提交
    • Y
      bnx2x: Remove the sriov VFOP mechanism · 2dc33bbc
      Yuval Mintz 提交于
      Since we now posses a workqueue dedicated for sriov, the paradigm that sriov-
      related tasks cannot sleep is no longer correct.
      
      The VFOP mechanism was the one previously supporting said paradigm - the sriov
      related tasks were broken into segments which did not require sleep, and the
      mechanism re-scheduled the next segment whenever possible.
      
      This patch remvoes the VFOP mechanism altogether - the resulting code is a much
      easier to follow code; The segments are gathered into straight-forward
      functions which sleep whenever neccessary.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2dc33bbc
    • Y
      bnx2x: Create workqueue for IOV related tasks · 370d4a26
      Yuval Mintz 提交于
      The bnx2x sriov mechanisms were done in the bnx2x slowpath workitem which
      runs on the bnx2x's workqueue; This workitem is also responsible for the bottom
      half of interrupt handling in the driver, and specifically it also receives
      FW notifications of ramrod completions, allowing other flows to progress.
      
      The original design of the sriov reltaed-flows was based on the notion such
      flows must not sleep, since their context is the slowpath workitem.
      Otherwise, we might reach timeouts - those flows may wait for ramrod completion
      that will never arrive as the workitem wlll not be re-scheduled until that same
      flow will be over.
      
      In more recent time bnx2x started supporting features in which the VF interface
      can be configured by the tools accessing the PF on the hypervisor.
      This support created possible races on the VF-PF lock (which is taken either
      when the PF is handling a VF message or when the PF is doing some slowpath work
      on behalf of the VF) which may cause timeouts on the VF side and lags on the PF
      side.
      
      This patch changes the scheme - it creates a new workqueue for sriov related
      tasks and moves all handling currently done in the slowpath task into the the
      new workqueue.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      370d4a26
    • Y
      bnx2x: Support mng. request for driver version · 42f8277f
      Yuval Mintz 提交于
      This adds support in a new management feature which needs the driver versions
      (bnx2x, bnx2fc and bnx2i) loaded for each interface.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42f8277f
  6. 13 2月, 2014 4 次提交
  7. 15 1月, 2014 1 次提交
  8. 14 1月, 2014 1 次提交
    • S
      bnx2x: namespace and dead code cleanups · a8f47eb7
      stephen hemminger 提交于
      Fix a bunch of whole lot of namespace issues with the Broadcom bnx2x driver
      found by running 'make namespacecheck'
      
       * global variables must be prefixed with bnx2x_
          naming a variable int_mode, or num_queue is invitation to disaster
      
       * make local functions static
      
       * move some inline's used in one file out of header
         (this driver has a bad case of inline-itis)
      
       * remove resulting dead code fallout
       	 bnx2x_pfc_statistic,
      	 bnx2x_emac_get_pfc_stat
       	 bnx2x_init_vlan_mac_obj,
         Looks like vlan mac support in this driver was a botch from day one
         either never worked, or not implemented or missing support functions
      
      Compile tested only.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8f47eb7
  9. 10 1月, 2014 1 次提交
  10. 06 1月, 2014 2 次提交
  11. 27 12月, 2013 2 次提交
  12. 20 12月, 2013 1 次提交
  13. 19 11月, 2013 1 次提交
  14. 22 10月, 2013 5 次提交
  15. 10 10月, 2013 1 次提交
  16. 29 9月, 2013 2 次提交
  17. 19 9月, 2013 1 次提交
  18. 14 9月, 2013 1 次提交
  19. 06 9月, 2013 1 次提交
  20. 30 8月, 2013 1 次提交
  21. 20 8月, 2013 1 次提交
  22. 14 8月, 2013 3 次提交
  23. 02 8月, 2013 1 次提交
    • Y
      bnx2x: Revising locking scheme for MAC configuration · 8b09be5f
      Yuval Mintz 提交于
      On very rare occasions, repeated load/unload stress test in the presence of
      our storage driver (bnx2i/bnx2fc) causes a kernel panic in bnx2x code
      (NULL pointer dereference). Stack traces indicate the issue happens during MAC
      configuration; thorough code review showed that indeed several races exist
      in which one thread can iterate over the list of configured MACs while another
      deletes entries from the same list.
      
      This patch adds a varient on the single-writer/Multiple-reader lock mechanism -
      It utilizes an already exsiting bottom-half lock, using it so that Whenever
      a writer is unable to continue due to the existence of another writer/reader,
      it pends its request for future deliverance.
      The writer / last readers will check for the existence of such requests and
      perform them instead of the original initiator.
      This prevents the writer from having to sleep while waiting for the lock
      to be accessible, which might cause deadlocks given the locks already
      held by the writer.
      
      Another result of this patch is that setting of Rx Mode is now made in
      sleepable context - Setting of Rx Mode is made under a bottom-half lock, which
      was always nontrivial for the bnx2x driver, as the HW/FW configuration requires
      wait for completions.
      Since sleep was impossible (due to the sleepless-context), various mechanisms
      were utilized to prevent the calling thread from sleep, but the truth was that
      when the caller thread (i.e, the one calling ndo_set_rx_mode()) returned, the
      Rx mode was still not set in HW/FW.
      
      bnx2x_set_rx_mode() will now overtly schedule for the Rx changes to be
      configured by the sp_rtnl_task which hold the RTNL lock and is sleepable
      context.
      Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: NAriel Elior <ariele@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b09be5f