1. 02 6月, 2015 1 次提交
  2. 18 2月, 2015 1 次提交
  3. 11 8月, 2014 1 次提交
  4. 28 5月, 2014 1 次提交
  5. 18 3月, 2014 1 次提交
  6. 15 9月, 2012 1 次提交
  7. 20 7月, 2012 1 次提交
  8. 18 7月, 2012 1 次提交
  9. 15 5月, 2012 3 次提交
    • J
      IB/qib: MADs with misset M_Keys should return failure · 3236b2d4
      Jim Foraker 提交于
      If a MAD is sent directly to the local HCA rather than placed on a QP
      and the MAD fails M_Key checks, there is no means to generate a
      timeout for the client, which may hang.  Instead we report
      IB_MAD_RESULT_FAILURE, which operates the same for on-the-wire
      packets, but will generate a send failure back to the client.
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NJim Foraker <foraker1@llnl.gov>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      3236b2d4
    • J
      IB/qib: Fix M_Key lease timeout handling · 6199c896
      Jim Foraker 提交于
      If a port has an M_Key lease set, the M_Key protect bits set to 1, and
      a SubnSet arrives with an invalid M_Key, an M_Key mismatch trap is
      generated, the lease timer begins as expected, and eventually the
      M_Key protect bits will be set back to 0 as per the spec.  However, if
      any other SMP with an invalid M_Key arrives, the lease timer is expired
      and the M_Key protect bits remain in force.
      
      This is not according to to spec.  In particular, C14-17 says that
      a lease timer that is underway is not affected by protection level
      checks (ie, at protection level 1, a SubnGet with a bad M_Key may be
      successful, but does not stop the timer), and C14-19 says that the timer
      shall stop when a valid M_Key has been received.  C14-19 is the only
      compliance statement that specifies a stopping condition for the timer.
      
      This behavior is magnified if the port's Master SM LID attribute
      points at itself.  In that case, the M_Key mismatch trap is sufficient to
      expire the timer, and the mkey lease attribute is rendered useless.
      Reviewed-by: NRam Vepa <ram.vepa@qlogic.com>
      Signed-off-by: NJim Foraker <foraker1@llnl.gov>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@qlogic.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      6199c896
    • T
      IB/qib: Correct ordering of reregister vs. port active events · 4ccf28a2
      Todd Rimmer 提交于
      When a port first goes active with SMA Set(PortInfo) and reregister
      bit set, the driver sends up the reregister event followed by a port
      active event.
      
      The problem is that in response to reregister event most apps try to
      issue a SA query of some sort, but that fails because port is not
      active.
      
      The qib driver needs to a trivial change to correct this behavior.
      
      This issue has been there for a while; however the recent serdes work
      has probably made the delay between the reregister event and the
      active event larger and hence opened the race far enough so that its
      being seen more often.
      
      The patch also changes the clientrereg local to a u8 and saves off the
      rereg bit into it.  The code following the nested subn_get_portinfo()
      now restores that bit per o14-12.2.1 with a logical OR from that copy.
      Reviewed-by: NRam Vepa <ram.vepa@qlogic.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@qlogic.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      4ccf28a2
  10. 26 2月, 2012 1 次提交
  11. 19 7月, 2011 1 次提交
  12. 15 3月, 2011 1 次提交
  13. 23 2月, 2011 1 次提交
  14. 11 1月, 2011 1 次提交
  15. 24 5月, 2010 1 次提交