1. 14 8月, 2013 2 次提交
    • S
    • S
      RDMA/cxgb4: Fix QP flush logic · 1cf24dce
      Steve Wise 提交于
      This patch makes following fixes in QP flush logic:
      
      - correctly flushes unsignaled WRs followed by a signaled WR
      - supports for flushing a CQ bound to multiple QPs
      - resets cidx_flush if a active queue starts getting HW CQEs again
      - marks WQ in error when we leave RTS. This was only being done for
        user queues, but we need it for kernel queues too so that
        post_send/post_recv will start returning the appropriate error
        synchronously
      - eats unsignaled read resp CQEs. HW always inserts CQEs so we must
        silently discard them if the read work request was unsignaled.
      - handles QP flushes with pending SW CQEs. The flush and out of order
        completion logic has a bug where if out of order completions are
        flushed but not yet polled by the consumer and the qp is then
        flushed then we end up inserting duplicate completions.
      - c4iw_flush_sq() should only flush wrs that have not already been
        flushed.  Since we already track where in the SQ we've flushed via
        sq.cidx_flush, just start at that point and flush any remaining.
        This bug only caused a problem in the presence of unsignaled work
        requests.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NVipul Pandya <vipul@chelsio.com>
      
      [ Fixed sparse warning due to htonl/ntohl confusion.  - Roland ]
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      1cf24dce
  2. 31 7月, 2013 1 次提交
  3. 17 4月, 2013 1 次提交
    • T
      RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled · 5b0c2759
      Thadeu Lima de Souza Cascardo 提交于
      Commit c079c287 ("RDMA/cxgb4: Fix error handling in create_qp()")
      broke SQ allocation.  Instead of falling back to host allocation when
      on-chip allocation fails, it tries to allocate both.  And when it
      does, and we try to free the address from the genpool using the host
      address, we hit a BUG and the system crashes as below.
      
      We create a new function that has the previous behavior and properly
      propagate the error, as intended.
      
          kernel BUG at /usr/src/packages/BUILD/kernel-ppc64-3.0.68/linux-3.0/lib/genalloc.c:340!
          Oops: Exception in kernel mode, sig: 5 [#1]
          SMP NR_CPUS=1024 NUMA pSeries
          Modules linked in: rdma_ucm rdma_cm ib_addr ib_cm iw_cm ib_sa ib_mad ib_uverbs iw_cxgb4 ib_core ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables fuse loop dm_mod ipv6 ipv6_lib sr_mod cdrom ibmveth(X) cxgb4 sg ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh ibmvscsic(X) scsi_transport_srp scsi_tgt scsi_mod
          Supported: Yes
          NIP: c00000000037d41c LR: d000000003913824 CTR: c00000000037d3b0
          REGS: c0000001f350ae50 TRAP: 0700   Tainted: G            X  (3.0.68-0.9-ppc64)
          MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24042482  XER: 00000001
          TASK = c0000001f6f2a840[3616] 'rping' THREAD: c0000001f3508000 CPU: 0
          GPR00: c0000001f6e875c8 c0000001f350b0d0 c000000000fc9690 c0000001f6e875c0
          GPR04: 00000000000c0000 0000000000010000 0000000000000000 c0000000009d482a
          GPR08: 000000006a170000 0000000000100000 c0000001f350b140 c0000001f6e875c8
          GPR12: d000000003915dd0 c000000003f40000 000000003e3ecfa8 c0000001f350bea0
          GPR16: c0000001f350bcd0 00000000003c0000 0000000000040100 c0000001f6e74a80
          GPR20: d00000000399a898 c0000001f6e74ac8 c0000001fad91600 c0000001f6e74ab0
          GPR24: c0000001f7d23f80 0000000000000000 0000000000000002 000000006a170000
          GPR28: 000000000000000c c0000001f584c8d0 d000000003925180 c0000001f6e875c8
          NIP [c00000000037d41c] .gen_pool_free+0x6c/0xf8
          LR [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
          Call Trace:
          [c0000001f350b0d0] [c0000001f350b180] 0xc0000001f350b180 (unreliable)
          [c0000001f350b170] [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
          [c0000001f350b210] [d00000000390fd70] .dealloc_sq+0x90/0xb0 [iw_cxgb4]
          [c0000001f350b280] [d00000000390fe08] .destroy_qp+0x78/0xf8 [iw_cxgb4]
          [c0000001f350b310] [d000000003912738] .c4iw_destroy_qp+0x208/0x2d0 [iw_cxgb4]
          [c0000001f350b460] [d000000003861874] .ib_destroy_qp+0x5c/0x130 [ib_core]
          [c0000001f350b510] [d0000000039911bc] .ib_uverbs_cleanup_ucontext+0x174/0x4f8 [ib_uverbs]
          [c0000001f350b5f0] [d000000003991568] .ib_uverbs_close+0x28/0x70 [ib_uverbs]
          [c0000001f350b670] [c0000000001e7b2c] .__fput+0xdc/0x278
          [c0000001f350b720] [c0000000001a9590] .remove_vma+0x68/0xd8
          [c0000001f350b7b0] [c0000000001a9720] .exit_mmap+0x120/0x160
          [c0000001f350b8d0] [c0000000000af330] .mmput+0x80/0x160
          [c0000001f350b960] [c0000000000b5d0c] .exit_mm+0x1ac/0x1e8
          [c0000001f350ba10] [c0000000000b8154] .do_exit+0x1b4/0x4b8
          [c0000001f350bad0] [c0000000000b84b0] .do_group_exit+0x58/0xf8
          [c0000001f350bb60] [c0000000000ce9f4] .get_signal_to_deliver+0x2f4/0x5d0
          [c0000001f350bc60] [c000000000017ee4] .do_signal_pending+0x6c/0x3e0
          [c0000001f350bdb0] [c0000000000182cc] .do_signal+0x74/0x78
          [c0000001f350be30] [c000000000009e74] do_work+0x24/0x28
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: <stable@vger.kernel.org>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5b0c2759
  4. 23 3月, 2013 1 次提交
  5. 14 3月, 2013 5 次提交
  6. 15 2月, 2013 1 次提交
  7. 01 10月, 2012 1 次提交
  8. 06 9月, 2012 1 次提交
  9. 19 5月, 2012 3 次提交
  10. 01 11月, 2011 3 次提交
  11. 15 10月, 2011 1 次提交
  12. 07 10月, 2011 1 次提交
  13. 18 6月, 2011 1 次提交
  14. 10 5月, 2011 2 次提交
  15. 15 3月, 2011 1 次提交
  16. 29 1月, 2011 1 次提交
  17. 11 1月, 2011 2 次提交
  18. 29 9月, 2010 8 次提交
  19. 28 9月, 2010 1 次提交
    • R
      RDMA/cxgb4: Fix warnings about casts to/from pointers of different sizes · c8e081a1
      Roland Dreier 提交于
      Fix:
      
        drivers/infiniband/hw/cxgb4/qp.c: In function ‘create_qp’:
        drivers/infiniband/hw/cxgb4/qp.c:147: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/qp.c: In function ‘rdma_fini’:
        drivers/infiniband/hw/cxgb4/qp.c:988: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/qp.c: In function ‘rdma_init’:
        drivers/infiniband/hw/cxgb4/qp.c:1063: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/mem.c: In function ‘write_adapter_mem’:
        drivers/infiniband/hw/cxgb4/mem.c:74: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/cq.c: In function ‘destroy_cq’:
        drivers/infiniband/hw/cxgb4/cq.c:58: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/cq.c: In function ‘create_cq’:
        drivers/infiniband/hw/cxgb4/cq.c:135: warning: cast from pointer to integer of different size
        drivers/infiniband/hw/cxgb4/cm.c: In function ‘fw6_msg’:
        drivers/infiniband/hw/cxgb4/cm.c:2326: warning: cast to pointer from integer of different size
      
      by casting pointers to unsigned long instead of u64.
      Reported-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      c8e081a1
  20. 03 8月, 2010 1 次提交
    • S
      RDMA/cxgb4: Fix race in fini path · 73d6fcad
      Steve Wise 提交于
      There exists a race condition where the app disconnects, which
      initiates an orderly close (via rdma_fini()), concurrently with an
      ingress abort condition, which initiates an abortive close operation.
      Since rdma_fini() must be called without IRQs disabled, the fini can
      be called after the QP has been transitioned to ERROR.  This is ok,
      but we need to protect against qp->ep getting NULLed.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      73d6fcad
  21. 22 7月, 2010 2 次提交