1. 22 5月, 2007 1 次提交
    • M
      IB/cm: Improve local id allocation · 9f81036c
      Michael S. Tsirkin 提交于
      The IB CM uses an idr for local id allocations, with a running counter
      as start_id.  This fails to generate distinct ids if
      
      1. An id is constantly created and destroyed
      2. A chunk of ids just beyond the current next_id value is occupied
      
      This in turn leads to an increased chance of connection request being
      mis-detected as a duplicate, sometimes for several retries, until
      next_id gets past the block of allocated ids. This has been observed
      in practice.
      
      As a fix, remember the last id allocated and start immediately above it.
      This also fixes a problem with the old code, where next_id might
      overflow and become negative.
      Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
      Acked-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      9f81036c
  2. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      Jean Delvare 提交于
      I noticed that many source files include <linux/pci.h> while they do
      not appear to need it. Here is an attempt to clean it all up.
      
      In order to find all possibly affected files, I searched for all
      files including <linux/pci.h> but without any other occurence of "pci"
      or "PCI". I removed the include statement from all of these, then I
      compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
      false positives manually.
      
      My tests covered 66% of the affected files, so there could be false
      positives remaining. Untested files are:
      
      arch/alpha/kernel/err_common.c
      arch/alpha/kernel/err_ev6.c
      arch/alpha/kernel/err_ev7.c
      arch/ia64/sn/kernel/huberror.c
      arch/ia64/sn/kernel/xpnet.c
      arch/m68knommu/kernel/dma.c
      arch/mips/lib/iomap.c
      arch/powerpc/platforms/pseries/ras.c
      arch/ppc/8260_io/enet.c
      arch/ppc/8260_io/fcc_enet.c
      arch/ppc/8xx_io/enet.c
      arch/ppc/syslib/ppc4xx_sgdma.c
      arch/sh64/mach-cayman/iomap.c
      arch/xtensa/kernel/xtensa_ksyms.c
      arch/xtensa/platform-iss/setup.c
      drivers/i2c/busses/i2c-at91.c
      drivers/i2c/busses/i2c-mpc.c
      drivers/media/video/saa711x.c
      drivers/misc/hdpuftrs/hdpu_cpustate.c
      drivers/misc/hdpuftrs/hdpu_nexus.c
      drivers/net/au1000_eth.c
      drivers/net/fec_8xx/fec_main.c
      drivers/net/fec_8xx/fec_mii.c
      drivers/net/fs_enet/fs_enet-main.c
      drivers/net/fs_enet/mac-fcc.c
      drivers/net/fs_enet/mac-fec.c
      drivers/net/fs_enet/mac-scc.c
      drivers/net/fs_enet/mii-bitbang.c
      drivers/net/fs_enet/mii-fec.c
      drivers/net/ibm_emac/ibm_emac_core.c
      drivers/net/lasi_82596.c
      drivers/parisc/hppb.c
      drivers/sbus/sbus.c
      drivers/video/g364fb.c
      drivers/video/platinumfb.c
      drivers/video/stifb.c
      drivers/video/valkyriefb.c
      include/asm-arm/arch-ixp4xx/dma.h
      sound/oss/au1550_ac97.c
      
      I would welcome test reports for these files. I am fine with removing
      the untested files from the patch if the general opinion is that these
      changes aren't safe. The tested part would still be nice to have.
      
      Note that this patch depends on another header fixup patch I submitted
      to LKML yesterday:
        [PATCH] scatterlist.h needs types.h
        http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  3. 23 2月, 2007 1 次提交
  4. 13 12月, 2006 1 次提交
  5. 30 11月, 2006 3 次提交
  6. 22 11月, 2006 1 次提交
  7. 11 10月, 2006 2 次提交
    • S
      IB/cm: Send DREP in response to unmatched DREQ · 82a9c16a
      Sean Hefty 提交于
      Currently a DREP is only sent in response to a DREQ if a connection
      has been found matching the DREQ, and it is in the proper state.  Once
      a DREP is sent, the local connection moves into timewait.  Duplicate
      DREQs received while in this state result in re-sending the DREP.
      
      However, it's likely that the local connection will enter and exit
      timewait before the remote side times out a lost DREP and resends a DREQ.
      To handle this, we send a DREP in response to a DREQ, even if a local
      connection is not found.  This avoids maintaining disconnected
      id's in timewait states for excessively long times, just to handle a
      lost DREP.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      82a9c16a
    • S
      IB/cm: Fix timewait crash after module unload · 8575329d
      Sean Hefty 提交于
      If the ib_cm module is unloaded while id's are still in timewait, the
      CM will destroy the work queue used to process timewait.  Once the
      id's exit timewait, their timers will fire, leading to a crash trying
      to access the destroyed work queue.
      
      We need to track id's that are in timewait, and cancel their deferred
      work on module unload.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      8575329d
  8. 23 9月, 2006 6 次提交
  9. 04 8月, 2006 1 次提交
  10. 15 7月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 18 6月, 2006 4 次提交
  13. 13 5月, 2006 1 次提交
    • S
      IB: refcount race fixes · 1b52fa98
      Sean Hefty 提交于
      Fix race condition during destruction calls to avoid possibility of
      accessing object after it has been freed.  Instead of waking up a wait
      queue directly, which is susceptible to a race where the object is
      freed between the reference count going to 0 and the wake_up(), use a
      completion to wait in the function doing the freeing.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      1b52fa98
  14. 21 3月, 2006 1 次提交
  15. 15 1月, 2006 1 次提交
  16. 10 1月, 2006 1 次提交
  17. 01 12月, 2005 2 次提交
  18. 02 11月, 2005 1 次提交
  19. 26 10月, 2005 1 次提交
    • S
      [IB] Fix MAD layer DMA mappings to avoid touching data buffer once mapped · 34816ad9
      Sean Hefty 提交于
      The MAD layer was violating the DMA API by touching data buffers used
      for sends after the DMA mapping was done.  This causes problems on
      non-cache-coherent architectures, because the device doing DMA won't
      see updates to the payload buffers that exist only in the CPU cache.
      
      Fix this by having all MAD consumers use ib_create_send_mad() to
      allocate their send buffers, and moving the DMA mapping into the MAD
      layer so it can be done just before calling send (and after any
      modifications of the send buffer by the MAD layer).
      
      Tested on a non-cache-coherent PowerPC 440SPe system.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      34816ad9
  20. 25 10月, 2005 2 次提交
  21. 18 10月, 2005 1 次提交
  22. 10 9月, 2005 2 次提交
  23. 27 8月, 2005 2 次提交
  24. 28 7月, 2005 1 次提交