1. 30 Aug, 2011 1 commit
  2. 26 Jul, 2011 1 commit
  3. 17 May, 2011 1 commit
    • Jens Axboe's avatar
      scsi: remove performance regression due to async queue run · 9937a5e2
      Jens Axboe authored
      Commit c21e6beb removed our queue request_fn re-enter
      protection, and defaulted to always running the queues from
      kblockd to be safe. This was a known potential slow down,
      but should be safe.
      
      Unfortunately this is causing big performance regressions for
      some, so we need to improve this logic. Looking into the details
      of the re-enter, the real issue is on requeue of requests.
      
      Requeue of requests upon seeing a BUSY condition from the device
      ends up re-running the queue, causing traces like this:
      
      scsi_request_fn()
              scsi_dispatch_cmd()
                      scsi_queue_insert()
                              __scsi_queue_insert()
                                      scsi_run_queue()
      					scsi_request_fn()
      						...
      
      potentially causing the issue we want to avoid. So special
      case the requeue re-run of the queue, but improve it to offload
      the entire run of local queue and starved queue from a single
      workqueue callback. This is a lot better than potentially
      kicking off a workqueue run for each device seen.
      
      This also fixes the issue of the local device going into recursion,
      since the above mentioned commit never moved that queue run out
      of line.
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      9937a5e2
  4. 23 Mar, 2011 1 commit
    • Krishnasamy, Somasundaram's avatar
      [SCSI] ses: Avoid kernel panic when lun 0 is not mapped · d1e12de8
      Krishnasamy, Somasundaram authored
      During device discovery, scsi mid layer sends INQUIRY command to LUN
      0. If the LUN 0 is not mapped to host, it creates a temporary
      scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After
      the REPORT_LUNS succeeds, it walks through the LUN table and adds each
      LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will
      delete the temporary scsi_device of LUN 0.
      
      When scsi devices are added to sysfs, it calls add_dev function of all
      the registered class interfaces. If ses driver has been registered,
      ses_intf_add() of ses module will be called. This function calls
      scsi_device_enclosure() to check the inquiry data for EncServ
      bit. Since inquiry was not allocated for temporary LUN 0 scsi_device,
      it will cause NULL pointer exception.
      
      To fix the problem, sdev->inquiry is checked for NULL before reading it.
      Signed-off-by: default avatarSomasundaram Krishnasamy <Somasundaram.Krishnasamy@lsi.com>
      Signed-off-by: default avatarBabu Moger <babu.moger@lsi.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      d1e12de8
  5. 24 Jan, 2011 1 commit
  6. 22 Oct, 2010 2 commits
    • Hans de Goede's avatar
      scsi/sd: add a no_read_capacity_16 scsi_device flag · 5ce524bd
      Hans de Goede authored
      I seem to have a knack for digging up buggy usb devices which don't work
      with Linux, and I'm crazy enough to try to make them work.  So this time a
      friend of mine asked me to get an mp4 player (an mp3 player which can play
      videos on a small screen) to work with Linux.
      
      It is based on the well known rockbox chipset for which we already have an
      unusual devs entries to work around some of its bugs.  But this model
      comes with an additional twist.
      
      This model chokes on read_capacity_16 calls.  Now normally we don't make
      those calls, but this model comes with an sdcard slot and when there is no
      card in there (and shipped from the factory there is none), it reports a
      size of 0.  However this time the programmers actually got the
      read_capacity_10 response right!  So they substract one from the size as
      stored internally in the mp3 player before reporting it back, resulting in
      an answer of ...  0xffffffff sectors, causing sd.c to try a
      read_capacity_16, on which the device crashes.
      
      This patch adds a flag to scsi_device to indicate that a a device cannot
      handle read_capacity_16, and when this flag is set if a device reports an
      lba of 0xffffffff as answer to a read_capacity_10, assumes it tries to
      report a size of 0.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5ce524bd
    • Hans de Goede's avatar
      scsi/sr: add no_read_disc_info scsi_device flag · 8e04d805
      Hans de Goede authored
      Some USB devices emulate a usb-mass-storage attached (scsi) cdrom device,
      usually this fake cdrom contains the windows software for the device.
      While working on supporting Appotech ax3003 based photoframes, which do
      this I discovered that they will go of into lala land when ever they see a
      READ_DISC_INFO scsi command.
      
      Thus this patch adds a scsi_device flag (which can then be set by the
      usb-storage driver through an unsual-devs entry), to indicate this, and
      makes the sr driver honor this flag.
      
      I know this sucks, but as discussed on linux-scsi list there is no other
      way to make this device work properly.
      
      Looking at usb traces made under windows, windows never sends a
      READ_DISC_INFO during normal interactions with a usb cdrom device.  So as
      this cdrom emulation thingie becomes more common we might see more of this
      problem.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8e04d805
  7. 28 Jul, 2010 1 commit
    • Alan Stern's avatar
      [SCSI] implement runtime Power Management · bc4f2401
      Alan Stern authored
      This patch (as1398b) adds runtime PM support to the SCSI layer.  Only
      the machanism is provided; use of it is up to the various high-level
      drivers, and the patch doesn't change any of them.  Except for sg --
      the patch expicitly prevents a device from being runtime-suspended
      while its sg device file is open.
      
      The implementation is simplistic.  In general, hosts and targets are
      automatically suspended when all their children are asleep, but for
      them the runtime-suspend code doesn't actually do anything.  (A host's
      runtime PM status is propagated up the device tree, though, so a
      runtime-PM-aware lower-level driver could power down the host adapter
      hardware at the appropriate times.)  There are comments indicating
      where a transport class might be notified or some other hooks added.
      
      LUNs are runtime-suspended by calling the drivers' existing suspend
      handlers (and likewise for runtime-resume).  Somewhat arbitrarily, the
      implementation delays for 100 ms before suspending an eligible LUN.
      This is because there typically are occasions during bootup when the
      same device file is opened and closed several times in quick
      succession.
      
      The way this all works is that the SCSI core increments a device's
      PM-usage count when it is registered.  If a high-level driver does
      nothing then the device will not be eligible for runtime-suspend
      because of the elevated usage count.  If a high-level driver wants to
      use runtime PM then it can call scsi_autopm_put_device() in its probe
      routine to decrement the usage count and scsi_autopm_get_device() in
      its remove routine to restore the original count.
      
      Hosts, targets, and LUNs are not suspended while they are being probed
      or removed, or while the error handler is running.  In fact, a fairly
      large part of the patch consists of code to make sure that things
      aren't suspended at such times.
      
      [jejb: fix up compile issues in PM config variations]
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      bc4f2401
  8. 18 Jan, 2010 1 commit
  9. 04 Dec, 2009 2 commits
    • Chandra Seetharaman's avatar
      [SCSI] scsi_dh: Change the scsidh_activate interface to be asynchronous · 3ae31f6a
      Chandra Seetharaman authored
      Make scsi_dh_activate() function asynchronous, by taking in two additional
      parameters, one is the callback function and the other is the data to call
      the callback function with.
      Signed-off-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      3ae31f6a
    • Vasu Dev's avatar
      [SCSI] add queue_depth ramp up code · 4a84067d
      Vasu Dev authored
      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: default avatarVasu Dev <vasu.dev@intel.com>
      Tested-by: default avatarChristof Schmitt <christof.schmitt@de.ibm.com>
      Tested-by: default avatarGiridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      4a84067d
  10. 26 Nov, 2009 1 commit
    • James Bottomley's avatar
      [SCSI] fix async scan add/remove race resulting in an oops · 860dc736
      James Bottomley authored
      Async scanning introduced a very wide window where the SCSI device is
      up and running but has not yet been added to sysfs.  We delay the
      adding until all scans have completed to retain the same ordering as
      sync scanning.
      
      This delay in visibility causes an oops if a device is removed before
      we make it visible because the SCSI removal routines have an inbuilt
      assumption that if a device is in SDEV_RUNNING state, it must be
      visible (which is not necessarily true in the async scanning case).
      
      Fix this by introducing an additional is_visible flag which we can use
      to condition the tear down so we do the right thing for running but
      not yet made visible.
      Reported-by: default avatarAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      860dc736
  11. 22 Aug, 2009 2 commits
  12. 12 Mar, 2009 3 commits
  13. 29 Dec, 2008 2 commits
  14. 13 Oct, 2008 1 commit
    • Mike Christie's avatar
      [SCSI] Add helper code so transport classes/driver can control queueing (v3) · f0c0a376
      Mike Christie authored
      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: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      f0c0a376
  15. 03 Oct, 2008 2 commits
  16. 06 Aug, 2008 1 commit
  17. 05 Aug, 2008 1 commit
  18. 04 Aug, 2008 1 commit
  19. 27 Jul, 2008 1 commit
    • Alan Jenkins's avatar
      [SCSI] extend the last_sector_bug flag to cover more sectors · 2b142900
      Alan Jenkins authored
      The last_sector_bug flag was added to work around a bug in certain usb
      cardreaders, where they would crash if a multiple sector read included the
      last sector. The original implementation avoids this by e.g. splitting an 8
      sector read which includes the last sector into a 7 sector read, and a single
      sector read for the last sector.  The flag is enabled for all USB devices.
      
      This revealed a second bug in other usb cardreaders, which crash when they
      get a multiple sector read which stops 1 sector short of the last sector.
      Affected hardware includes the Kingston "MobileLite" external USB cardreader
      and the internal USB cardreader on the Asus EeePC.
      
      Extend the last_sector_bug workaround to ensure that any access which touches
      the last 8 hardware sectors of the device is a single sector long.  Requests
      are shrunk as necessary to meet this constraint.
      
      This gives us a safety margin against potential unknown or future bugs
      affecting multi-sector access to the end of the device.  The two known bugs
      only affect the last 2 sectors.  However, they suggest that these devices
      are prone to fencepost errors and that multi-sector access to the end of the
      device is not well tested.  Popular OS's use multi-sector accesses, but they
      rarely read the last few sectors.  Linux (with udev & vol_id) automatically
      reads sectors from the end of the device on insertion.  It is assumed that
      single sector accesses are more thoroughly tested during development.
      Signed-off-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Tested-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      2b142900
  20. 26 Jul, 2008 2 commits
  21. 14 Jul, 2008 1 commit
    • Stefan Richter's avatar
      scsi: sd: optionally set power condition in START STOP UNIT · d2886ea3
      Stefan Richter authored
      Adds a new scsi_device flag, start_stop_pwr_cond:  If enabled, the sd
      driver will not send plain START STOP UNIT commands but ones with the
      power condition field set to 3 (standby) or 1 (active) respectively.
      
      Some FireWire disk firmwares do not stop the motor if power condition is
      zero.  Or worse, they become unresponsive after a START STOP UNIT with
      power condition = 0 and start = 0.
      
      http://lkml.org/lkml/2008/4/29/704
      
      This patch only adds the necessary code to sd_mod but doesn't activate
      it.  Follow-up patches to the FireWire drivers will add detection of
      affected devices and enable the code for them.
      
      I did not add power condition values to scsi_error.c::scsi_eh_try_stu()
      for now.  The three firmwares which suffer from above mentioned problems
      do not need START STOP UNIT in the error handler, and they are not
      adversely affected by START STOP UNIT with power condition = 0 and start
      = 1 (like scsi_eh_try_stu() sends it if scsi_device.allow_restart is
      enabled).
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Tested-by: default avatarTino Keitel <tino.keitel@gmx.de>
      d2886ea3
  22. 05 Jun, 2008 1 commit
  23. 22 Apr, 2008 1 commit
    • James Bottomley's avatar
      [SCSI] rework scsi_target allocation · 643eb2d9
      James Bottomley authored
      The current target allocation code registeres each possible target
      with sysfs; it will be deleted again if no useable LUN on this target
      was found. This results in a string of 'target add/target remove' uevents.
      
      Based on a patch by Hannes Reinecke <hare@suse.de> this patch reworks
      the target allocation code so that only uevents for existing targets
      are sent. The sysfs registration is split off from the existing
      scsi_target_alloc() into a in a new scsi_add_target() function, which
      should be called whenever an existing target is found. Only then a
      uevent is sent, so we'll be generating events for existing targets
      only.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      643eb2d9
  24. 19 Apr, 2008 1 commit
  25. 23 Jan, 2008 2 commits
  26. 11 Jan, 2008 2 commits
    • James Bottomley's avatar
      [SCSI] sd,sr: add early detection of medium not present · 001aac25
      James Bottomley authored
      The current scsi_test_unit_ready() is updated to return sense code
      information (in struct scsi_sense_hdr).  The sd and sr drivers are
      changed to interpret the sense code return asc 0x3a as no media and
      adjust the device status accordingly.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      001aac25
    • Tony Battersby's avatar
      [SCSI] move single_lun flag from scsi_device to scsi_target · 25d7c363
      Tony Battersby authored
      Some SCSI tape medium changers that need the BLIST_SINGLELUN flag have
      the medium changer at one LUN and the tape drive at a different LUN.
      The inquiry string of the tape drive may be different from that of the
      medium changer.  In order for single_lun to be effective, every
      scsi_device under a given scsi_target must have it set.  This means that
      there needs to be a blacklist entry for BOTH the medium changer AND the
      tape drive, which is impractical because some medium changers may be
      paired with a variety of different tape drive models.  It makes more
      sense to put the single_lun flag in scsi_target instead of scsi_device,
      which causes every device at a given target ID to inherit the single_lun
      flag from one LUN.  This makes it possible to blacklist just the medium
      changer and not the tape drive.
      Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      25d7c363
  27. 10 Dec, 2007 1 commit
  28. 03 Nov, 2007 1 commit
  29. 14 Jul, 2007 1 commit
  30. 19 Jun, 2007 1 commit