1. 03 11月, 2006 1 次提交
  2. 31 10月, 2006 2 次提交
  3. 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
  4. 03 10月, 2006 5 次提交
  5. 29 9月, 2006 1 次提交
  6. 27 9月, 2006 1 次提交
  7. 24 9月, 2006 1 次提交
  8. 23 9月, 2006 16 次提交
  9. 15 9月, 2006 1 次提交
  10. 17 8月, 2006 1 次提交
  11. 04 8月, 2006 2 次提交
  12. 03 8月, 2006 1 次提交
  13. 25 7月, 2006 1 次提交
  14. 24 7月, 2006 2 次提交
  15. 15 7月, 2006 3 次提交