1. 28 Feb, 2018 10 commits
  2. 23 Feb, 2018 14 commits
  3. 22 Feb, 2018 1 commit
  4. 15 Feb, 2018 13 commits
  5. 14 Feb, 2018 2 commits
    • Martin Wilck's avatar
      scsi: scsi_debug: reset injection flags for every_nth > 0 · f9ba7af8
      Martin Wilck authored
      If every_nth > 0, the injection flags must be reset for commands that
      aren't supposed to fail (i.e. that aren't "nth"). Otherwise, commands
      will continue to fail, like in the every_nth < 0 case.
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.com>
      Acked-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      f9ba7af8
    • Douglas Gilbert's avatar
      scsi: scsi_debug: implement IMMED bit · 80c49563
      Douglas Gilbert authored
      The Start Stop Unit (SSU) command takes in the order of a second to complete
      on some SAS SSDs and longer on hard disks. Synchronize Cache (SC) can also
      take some time. Both commands have an IMMED bit in their cdbs for those apps
      that don't want to wait. This patch introduces a long delay for those commands
      when the IMMED bit is clear.  Since SC is a media access command then when the
      fake_rw option is active, its cdb processing is skipped and it returns
      immediately. The SSU command is not altered by the setting of the fake_rw
      option. These actions are not changed by this patch.
      
      Changes since v1:
        - clear the cdb mask of SYNCHRONIZE CACHE(16) cdb in byte 1, bit 0
      
      Changes:
        - add the SYNCHRONIZE CACHE(16) command
        - together with the existing START STOP UNIT and SYNCHRONIZE CACHE(10)
          commands process the IMMED bit in their cdbs
        - if the IMMED bit is set, return immediately
        - if the IMMED bit is clear, treat the delay parameter as having
          a unit of one second
        - in the SYNCHRONIZE CACHE processing do a bounds check
      Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      80c49563