1. 12 7月, 2008 13 次提交
  2. 24 5月, 2008 1 次提交
  3. 21 5月, 2008 3 次提交
    • J
      IPoIB: Test for NULL broadcast object in ipiob_mcast_join_finish() · e1d50dce
      Jack Morgenstein 提交于
      We saw a kernel oops in our regression testing when a multicast "join
      finish" occurred just after the interface was -- this is
      <https://bugs.openfabrics.org/show_bug.cgi?id=1040>.  The test
      randomly causes the HCA physical port to go down then up.
      
      The cause of this is that ipoib_mcast_join_finish() processing happen
      just after ipoib_mcast_dev_flush() was invoked (in which case the
      broadcast pointer is NULL).  This patch tests for and handles the case
      where priv->broadcast is NULL.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      e1d50dce
    • R
      IB/mlx4: Fix creation of kernel QP with max number of send s/g entries · cd155c1c
      Roland Dreier 提交于
      When creating a kernel QP where the consumer asked for a send queue
      with lots of scatter/gater entries, set_kernel_sq_size() incorrectly
      returned an error if the send queue stride is larger than the
      hardware's maximum send work request descriptor size.  This is not a
      problem; the only issue is to make sure that the actual descriptors
      used do not overflow the maximum descriptor size, so check this instead.
      
      Clamp the returned max_send_sge value to be no bigger than what
      query_device returns for the max_sge to avoid confusing hapless users,
      even if the hardware is capable of handling a few more s/g entries.
      
      This bug caused NFS/RDMA mounts to fail when the server adapter used
      the mlx4 driver.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      cd155c1c
    • G
      IB: fix race in device_create · 6c06aec2
      Greg Kroah-Hartman 提交于
      There is a race from when a device is created with device_create() and
      then the drvdata is set with a call to dev_set_drvdata() in which a
      sysfs file could be open, yet the drvdata will be NULL, causing all
      sorts of bad things to happen.
      
      This patch fixes the problem by using the new function,
      device_create_drvdata().
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Reviewed-by: NRoland Dreier <rolandd@cisco.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6c06aec2
  4. 17 5月, 2008 3 次提交
  5. 16 5月, 2008 2 次提交
    • R
      IB/ipath: Fix UC receive completion opcode for RDMA WRITE with immediate · df3f0da8
      Ralph Campbell 提交于
      When I fixed the RC receive completion opcode in 2bfc8e9e ("IB/ipath:
      Return the correct opcode for RDMA WRITE with immediate"), I forgot to
      fix UC, which had the same problem for RDMA write with immediate
      returning the wrong opcode.
      Signed-off-by: NRalph Campbell <ralph.campbell@qlogic.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      df3f0da8
    • R
      IB/ipath: Fix printk format for ipath_sdma_status · cd80ec6f
      Roland Dreier 提交于
      Commit f018c7e1 ("IB/ipath: Change ipath_devdata.ipath_sdma_status to be
      unsigned long") changed ipath_sdma_status to be unsigned long, but left
      a few debug messages that printed it out with a %016llx format, which
      generates the warnings
      
          drivers/infiniband/hw/ipath/ipath_sdma.c:348: warning: format '%016llx' expects type 'long long unsigned int', but argument  3 has type 'long unsigned int'
          drivers/infiniband/hw/ipath/ipath_sdma.c:618: warning: format '%016llx' expects type 'long long unsigned int', but argument  3 has type 'long unsigned int'
      
      Fix this by changing the format used to print out the value to %08lx
      (8 hex digits are now sufficient, because the highest bit used is 31).
      
      Warnings reported by Randy Dunlap <randy.dunlap@oracle.com>.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      cd80ec6f
  6. 14 5月, 2008 7 次提交
  7. 08 5月, 2008 8 次提交
  8. 07 5月, 2008 2 次提交
    • R
      RDMA/cxgb3: Fix severe limit on userspace memory registration size · 273748cc
      Roland Dreier 提交于
      Currently, iw_cxgb3 is severely limited on the amount of userspace
      memory that can be registered in in a single memory region, which
      causes big problems for applications that expect to be able to
      register 100s of MB.
      
      The problem is that the driver uses a single kmalloc()ed buffer to
      hold the physical buffer list (PBL) for the entire memory region
      during registration, which means that 8 bytes of contiguous memory are
      required for each page of memory being registered.  For example, a 64
      MB registration will require 128 KB of contiguous memory with 4 KB
      pages, and it unlikely that such an allocation will succeed on a busy
      system.
      
      This is purely a driver problem: the temporary page list buffer is not
      needed by the hardware, so we can fix this by writing the PBL to the
      hardware in page-sized chunks rather than all at once.  We do this by
      splitting the memory registration operation up into several steps:
      
       - Allocate PBL space in adapter memory for the full registration
       - Copy PBL to adapter memory in chunks
       - Allocate STag and enable memory region
      
      This also allows several other cleanups to the __cxio_tpt_op()
      interface and related parts of the driver.
      
      This change leaves the reregister memory region and memory window
      operations broken, but they already didn't work due to other
      longstanding bugs, so fixing them will be left to a later patch.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      273748cc
    • R
      RDMA/cxgb3: Don't add PBL memory to gen_pool in chunks · 0e991336
      Roland Dreier 提交于
      Current iw_cxgb3 code adds PBL memory to the driver's gen_pool in 2 MB
      chunks.  This limits the largest single allocation that can be done to
      the same size, which means that with 4 KB pages, each of which takes 8
      bytes of PBL memory, the largest memory region that can be allocated
      is 1 GB (256K PBL entries * 4 KB/entry).
      
      Remove this limit by adding all the PBL memory in a single gen_pool
      chunk, if possible.  Add code that falls back to smaller chunks if
      gen_pool_add() fails, which can happen if there is not sufficient
      contiguous lowmem for the internal gen_pool bitmap.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      0e991336
  9. 06 5月, 2008 1 次提交