1. 18 7月, 2014 4 次提交
  2. 11 4月, 2014 1 次提交
    • D
      scsi: async sd resume · 3c31b52f
      Dan Williams 提交于
      async_schedule() sd resume work to allow disks and other devices to
      resume in parallel.
      
      This moves the entirety of scsi_device resume to an async context to
      ensure that scsi_device_resume() remains ordered with respect to the
      completion of the start/stop command.  For the duration of the resume,
      new command submissions (that do not originate from the scsi-core) will
      be deferred (BLKPREP_DEFER).
      
      It adds a new ASYNC_DOMAIN_EXCLUSIVE(scsi_sd_pm_domain) as a container
      of these operations.  Like scsi_sd_probe_domain it is flushed at
      sd_remove() time to ensure async ops do not continue past the
      end-of-life of the sdev.  The implementation explicitly refrains from
      reusing scsi_sd_probe_domain directly for this purpose as it is flushed
      at the end of dpm_resume(), potentially defeating some of the benefit.
      Given sdevs are quiesced it is permissible for these resume operations
      to bleed past the async_synchronize_full() calls made by the driver
      core.
      
      We defer the resolution of which pm callback to call until
      scsi_dev_type_{suspend|resume} time and guarantee that the callback
      parameter is never NULL.  With this in place the type of resume
      operation is encoded in the async function identifier.
      
      There is a concern that async resume could trigger PSU overload.  In the
      enterprise, storage enclosures enforce staggered spin-up regardless of
      what the kernel does making async scanning safe by default.  Outside of
      that context a user can disable asynchronous scanning via a kernel
      command line or CONFIG_SCSI_SCAN_ASYNC.  Honor that setting when
      deciding whether to do resume asynchronously.
      
      Inspired by Todd's analysis and initial proposal [2]:
      https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Phillip Susi <psusi@ubuntu.com>
      [alan: bug fix and clean up suggestion]
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Suggested-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
      [djbw: kick all resume work to the async queue]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3c31b52f
  3. 27 3月, 2014 5 次提交
  4. 16 3月, 2014 2 次提交
  5. 19 12月, 2013 2 次提交
    • H
      [SCSI] Update documentation · 6ad55502
      Hannes Reinecke 提交于
      The documentation has gone out-of-sync, so update it to
      the current status.
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6ad55502
    • H
      [SCSI] improved eh timeout handler · e494f6a7
      Hannes Reinecke 提交于
      When a command runs into a timeout we need to send an 'ABORT TASK'
      TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
      
      Conceptually, however, this function is a normal SCSI command, so
      there is no need to enter the error handler.
      
      This patch implements a new scsi_abort_command() function which
      invokes an asynchronous function scsi_eh_abort_handler() to
      abort the commands via the usual 'eh_abort_handler'.
      
      If abort succeeds the command is either retried or terminated,
      depending on the number of allowed retries. However, 'eh_eflags'
      records the abort, so if the retry would fail again the
      command is pushed onto the error handler without trying to
      abort it (again); it'll be cleared up from SCSI EH.
      
      [hare: smatch detected stray switch fixed]
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e494f6a7
  6. 25 10月, 2013 1 次提交
  7. 03 8月, 2013 1 次提交
  8. 27 6月, 2013 1 次提交
    • M
      [SCSI] sd: Update WRITE SAME heuristics · 66c28f97
      Martin K. Petersen 提交于
      SATA drives located behind a SAS controller would incorrectly receive
      WRITE SAME commands. Tweak the heuristics so that:
      
       - If REPORT SUPPORTED OPERATION CODES is provided we will use that to
         choose between WRITE SAME(16), WRITE SAME(10) and disabled. This also
         fixes an issue with the old code which would issue WRITE SAME(10)
         despite the command not being whitelisted in REPORT SUPPORTED
         OPERATION CODES.
      
       - If REPORT SUPPORTED OPERATION CODES is not provided we will fall back
         to WRITE SAME(10) unless the device has an ATA Information VPD page.
         The assumption is that a SATL which is smart enough to implement
         WRITE SAME would also provide REPORT SUPPORTED OPERATION CODES.
      
      To facilitate the new heuristics scsi_report_opcode() has been modified
      to so we can distinguish between "operation not supported" and "RSOC not
      supported".
      Reported-by: NH. Peter Anvin <hpa@zytor.com>
      Tested-by: NBernd Schubert <bernd.schubert@itwm.fraunhofer.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      66c28f97
  9. 14 11月, 2012 1 次提交
  10. 20 7月, 2012 2 次提交
  11. 07 6月, 2012 1 次提交
  12. 17 5月, 2012 1 次提交
    • D
      [SCSI] sd: limit the scope of the async probe domain · a7a20d10
      Dan Williams 提交于
      sd injects and synchronizes probe work on the global kernel-wide domain.
      This runs into conflict with PM that wants to perform resume actions in
      async context:
      
      [  494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
      [  494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  494.360809] kworker/u:3     D 0000000000000000     0   554      2 0x00000000
      [  494.420739]  ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
      [  494.484392]  ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
      [  494.548038]  ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
      [  494.611685] Call Trace:
      [  494.632649]  [<ffffffff8149dd25>] schedule+0x5a/0x5c
      [  494.674687]  [<ffffffff8104b968>] async_synchronize_cookie_domain+0xb6/0x112
      [  494.734177]  [<ffffffff810461ff>] ? __init_waitqueue_head+0x50/0x50
      [  494.787134]  [<ffffffff8131a224>] ? scsi_remove_target+0x48/0x48
      [  494.837900]  [<ffffffff8104b9d9>] async_synchronize_cookie+0x15/0x17
      [  494.891567]  [<ffffffff8104ba49>] async_synchronize_full+0x54/0x70  <-- here we wait for async contexts to complete
      [  494.943783]  [<ffffffff8104b9f5>] ? async_synchronize_full_domain+0x1a/0x1a
      [  495.002547]  [<ffffffffa00114b1>] sd_remove+0x2c/0xa2 [sd_mod]
      [  495.051861]  [<ffffffff812fe94f>] __device_release_driver+0x86/0xcf
      [  495.104807]  [<ffffffff812fe9bd>] device_release_driver+0x25/0x32  <-- here we take device_lock()
      
      [  853.511341] INFO: task kworker/u:4:549 blocked for more than 120 seconds.
      [  853.568693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  853.635119] kworker/u:4     D ffff88013097b5d0     0   549      2 0x00000000
      [  853.695129]  ffff880132773c40 0000000000000046 ffff880130790000 ffff880132773fd8
      [  853.758990]  ffff880132773fd8 0000000000012500 ffff88013288a0b0 ffff880130790000
      [  853.822796]  0000000000000246 0000000000000040 ffff88013097b5c8 ffff880130790000
      [  853.886633] Call Trace:
      [  853.907631]  [<ffffffff8149dd25>] schedule+0x5a/0x5c
      [  853.949670]  [<ffffffff8149cc44>] __mutex_lock_common+0x220/0x351
      [  854.001225]  [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
      [  854.049082]  [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
      [  854.097011]  [<ffffffff8149ce48>] mutex_lock_nested+0x2f/0x36   <-- here we wait for device_lock()
      [  854.145591]  [<ffffffff81304bd7>] device_resume+0x58/0x1c4
      [  854.192066]  [<ffffffff81304d61>] async_resume+0x1e/0x45
      [  854.237019]  [<ffffffff8104bc93>] async_run_entry_fn+0xc6/0x173  <-- ...while running in async context
      
      Provide a 'scsi_sd_probe_domain' so that async probe actions actions can
      be flushed without regard for the state of PM, and allow for the resume
      path to handle devices that have transitioned from SDEV_QUIESCE to
      SDEV_DEL prior to resume.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      [alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      [jejb: remove unneeded config guards in include file]
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      a7a20d10
  13. 20 2月, 2012 1 次提交
    • M
      [SCSI] Handle disk devices which can not process medium access commands · 18a4d0a2
      Martin K. Petersen 提交于
      We have experienced several devices which fail in a fashion we do not
      currently handle gracefully in SCSI. After a failure these devices will
      respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.)
      but any command accessing the storage medium will time out.
      
      The following patch adds an callback that can be used by upper level
      drivers to inspect the results of an error handling command. This in
      turn has been used to implement additional checking in the SCSI disk
      driver.
      
      If a medium access command fails twice but TEST UNIT READY succeeds both
      times in the subsequent error handling we will offline the device. The
      maximum number of failed commands required to take a device offline can
      be tweaked in sysfs.
      
      Also add a new error flag to scsi_debug which allows this scenario to be
      easily reproduced.
      
      [jejb: fix up integer parsing to use kstrtouint]
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      18a4d0a2
  14. 17 11月, 2010 1 次提交
    • J
      SCSI host lock push-down · f281233d
      Jeff Garzik 提交于
      Move the mid-layer's ->queuecommand() invocation from being locked
      with the host lock to being unlocked to facilitate speeding up the
      critical path for drivers who don't need this lock taken anyway.
      
      The patch below presents a simple SCSI host lock push-down as an
      equivalent transformation.  No locking or other behavior should change
      with this patch.  All existing bugs and locking orders are preserved.
      
      Additionally, add one parameter to queuecommand,
      	struct Scsi_Host *
      and remove one parameter from queuecommand,
      	void (*done)(struct scsi_cmnd *)
      
      Scsi_Host* is a convenient pointer that most host drivers need anyway,
      and 'done' is redundant to struct scsi_cmnd->scsi_done.
      
      Minimal code disturbance was attempted with this change.  Most drivers
      needed only two one-line modifications for their host lock push-down.
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      Acked-by: NJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f281233d
  15. 16 9月, 2010 1 次提交
  16. 01 5月, 2010 1 次提交
  17. 02 3月, 2010 1 次提交
  18. 19 1月, 2010 1 次提交
  19. 05 12月, 2009 1 次提交
    • V
      [SCSI] add queue_depth ramp up code · 4a84067d
      Vasu Dev 提交于
      Current FC HBA queue_depth ramp up code depends on last queue
      full time. The sdev already  has last_queue_full_time field to
      track last queue full time but stored value is truncated by
      last four bits.
      
      So this patch updates last_queue_full_time without truncating
      last 4 bits to store full value and then updates its only
      current usages in scsi_track_queue_full to ignore last four bits
      to keep current usages same while also use this field
      in added ramp up code.
      
      Adds scsi_handle_queue_ramp_up to ramp up queue_depth on
      successful completion of IO. The scsi_handle_queue_ramp_up will
      do ramp up on all luns of a target, just same as ramp down done
      on all luns on a target.
      
      The ramp up is skipped in case the change_queue_depth is not
      supported by LLD or already reached to added max_queue_depth.
      
      Updates added max_queue_depth on every new update to default
      queue_depth value.
      
      The ramp up is also skipped if lapsed time since either last
      queue ramp up or down is less than LLD specified
      queue_ramp_up_period.
      
      Adds queue_ramp_up_period to sysfs but only if change_queue_depth
      is supported since ramp up and queue_ramp_up_period is needed only
      in case change_queue_depth is supported first.
      
      Initializes queue_ramp_up_period to 120HZ jiffies as initial
      default value, it is same as used in existing lpfc and qla2xxx.
      
      -v2
       Combined all ramp code into this single patch.
      
      -v3
       Moves max_queue_depth initialization after slave_configure is
      called from after slave_alloc calling done. Also adjusted
      max_queue_depth check to skip ramp up if current queue_depth
      is >= max_queue_depth.
      
      -v4
       Changes sdev->queue_ramp_up_period unit to ms when using sysfs i/f
      to store or show its value.
      Signed-off-by: NVasu Dev <vasu.dev@intel.com>
      Tested-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Tested-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      4a84067d
  20. 02 10月, 2009 1 次提交
  21. 23 8月, 2009 1 次提交
  22. 09 6月, 2009 1 次提交
  23. 03 4月, 2009 1 次提交
  24. 13 3月, 2009 1 次提交
  25. 14 1月, 2009 1 次提交
  26. 03 1月, 2009 1 次提交
  27. 13 10月, 2008 1 次提交
    • M
      [SCSI] Add helper code so transport classes/driver can control queueing (v3) · f0c0a376
      Mike Christie 提交于
      SCSI-ml manages the queueing limits for the device and host, but
      does not do so at the target level. However something something similar
      can come in userful when a driver is transitioning a transport object to
      the the blocked state, becuase at that time we do not want to queue
      io and we do not want the queuecommand to be called again.
      
      The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
      You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
      a transport level queueing issue like the hw cannot allocate some
      resource at the iscsi session/connection level, or the target has temporarily
      closed or shrunk the queueing window, or if we are transitioning
      to the blocked state.
      
      bnx2i, when they rework their firmware according to netdev
      developers requests, will also need to be able to limit queueing at this
      level. bnx2i will hook into libiscsi, but will allocate a scsi host per
      netdevice/hba, so unlike pure software iscsi/iser which is allocating
      a host per session, it cannot set the scsi_host->can_queue and return
      SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.
      
      The iscsi class/driver can also set a scsi_target->can_queue value which
      reflects the max commands the driver/class can support. For iscsi this
      reflects the number of commands we can support for each session due to
      session/connection hw limits, driver limits, and to also reflect the
      session/targets's queueing window.
      
      Changes:
      v1 - initial patch.
      v2 - Fix scsi_run_queue handling of multiple blocked targets.
      Previously we would break from the main loop if a device was added back on
      the starved list. We now run over the list and check if any target is
      blocked.
      v3 - Rediff for scsi-misc.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f0c0a376
  28. 09 10月, 2008 1 次提交
  29. 04 10月, 2008 1 次提交
  30. 27 7月, 2008 1 次提交