1. 29 Dec, 2008 2 commits
  2. 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.
      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
      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>
  3. 03 Oct, 2008 2 commits
  4. 06 Aug, 2008 1 commit
  5. 05 Aug, 2008 1 commit
  6. 04 Aug, 2008 1 commit
  7. 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>
  8. 26 Jul, 2008 2 commits
  9. 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.
      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
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Tested-by: default avatarTino Keitel <tino.keitel@gmx.de>
  10. 05 Jun, 2008 1 commit
  11. 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
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
  12. 19 Apr, 2008 1 commit
  13. 23 Jan, 2008 2 commits
  14. 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>
    • 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>
  15. 10 Dec, 2007 1 commit
  16. 03 Nov, 2007 1 commit
  17. 14 Jul, 2007 1 commit
  18. 19 Jun, 2007 1 commit
  19. 17 Apr, 2007 1 commit
    • Michael Tokarev's avatar
      [SCSI] modalias for scsi devices · d7b8bcb0
      Michael Tokarev authored
      The following patch adds support for sysfs/uevent modalias
      attribute for scsi devices (like disks, tapes, cdroms etc),
      based on whatever current sd.c, sr.c, st.c and osst.c drivers
      The modalias format is like this:
      (for TYPE_WORM, handled by sr.c now).
      Several comments.
      o This hexadecimal type value is because all TYPE_XXX constants
        in include/scsi/scsi.h are given in hex, but __stringify() will
        not convert them to decimal (so it will NOT be scsi:type-4).
        Since it does not really matter in which format it is, while
        both modalias in module and modalias attribute match each other,
        I descided to go for that 0x%02x format (and added a comment in
        include/scsi/scsi.h to keep them that way), instead of changing
        them all to decimal.
      o There was no .uevent routine for SCSI bus.  It might be a good
        idea to add some more ueven environment variables in there.
      o osst.c driver handles tapes too, like st.c, but only SOME tapes.
        With this setup, hotplug scripts (or whatever is used by the
        user) will try to load both st and osst modules for all SCSI
        tapes found, because both modules have scsi:type-0x01 alias).
        It is not harmful, but one extra module is no good either.
        It is possible to solve this, by exporting more info in
        modalias attribute, including vendor and device identification
        strings, so that modalias becomes something like
          scsi:type-0x12:vendor-Adaptec LTD:device-OnStream Tape Drive
        and having that, match for all 3 attributes, not only device
        type.  But oh well, vendor and device strings may be large,
        and they do contain spaces and whatnot.
        So I left them for now, awaiting for comments first.
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  20. 20 Mar, 2007 1 commit
    • Tejun Heo's avatar
      [SCSI] sd: implement START/STOP management · c3c94c5a
      Tejun Heo authored
      Implement SBC START/STOP management.  sdev->mange_start_stop is added.
      When it's set to one, sd STOPs the device on suspend and shutdown and
      STARTs it on resume.  sdev->manage_start_stop defaults is in sdev
      instead of scsi_disk cdev to allow ->slave_config() override the
      default configuration but is exported under scsi_disk sysfs node as
      sdev->allow_restart is.
      When manage_start_stop is zero (the default value), this patch doesn't
      introduce any behavior change.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Rejections fixed and
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  21. 11 Mar, 2007 1 commit
  22. 16 Feb, 2007 1 commit
  23. 11 Oct, 2006 1 commit
    • Matthew Wilcox's avatar
      [SCSI] Add ability to scan scsi busses asynchronously · 3e082a91
      Matthew Wilcox authored
      Since it often takes around 20-30 seconds to scan a scsi bus, it's
      highly advantageous to do this in parallel with other things.  The bulk
      of this patch is ensuring that devices don't change numbering, and that
      all devices are discovered prior to trying to start init.  For those
      who build SCSI as modules, there's a new scsi_wait_scan module that will
      ensure all bus scans are finished.
      This patch only handles drivers which call scsi_scan_host.  Fibre Channel,
      SAS, SATA, USB and Firewire all need additional work.
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  24. 30 Sep, 2006 1 commit
  25. 27 Sep, 2006 1 commit
  26. 19 Mar, 2006 1 commit
  27. 14 Mar, 2006 1 commit
  28. 27 Feb, 2006 3 commits
  29. 26 Jan, 2006 1 commit
    • brking@us.ibm.com's avatar
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com authored
      When the scsi_execute_async interface was added it ended up reducing
      the flexibility of userspace to send arbitrary scsi commands through
      sg using SG_IO. The SG_IO interface allows userspace to specify the
      CDB length. This is now ignored in scsi_execute_async and it is
      guessed using the COMMAND_SIZE macro, which is not always correct,
      particularly for vendor specific commands. This patch adds a cmd_len
      parameter to the scsi_execute_async interface to allow the caller
      to specify the length of the CDB.
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  30. 14 Dec, 2005 1 commit
    • Mike Christie's avatar
      [SCSI] Convert SCSI mid-layer to scsi_execute_async · 6e68af66
      Mike Christie authored
      Add scsi helpers to create really-large-requests and convert
      scsi-ml to scsi_execute_async().
      Per Jens's previous comments, I placed this function in scsi_lib.c.
      I made it follow all the queue's limits - I think I did at least :), so
      I removed the warning on the function header.
      I think the scsi_execute_* functions should eventually take a request_queue
      and be placed some place where the dm-multipath hw_handler can use them
      if that failover code is going to stay in the kernel. That conversion
      patch will be sent in another mail though.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  31. 13 Dec, 2005 1 commit
  32. 28 Oct, 2005 2 commits