1. 06 11月, 2008 1 次提交
  2. 13 10月, 2008 3 次提交
    • J
      [SCSI] scsi_error: fix target reset handling · c82dc88d
      James Bottomley 提交于
      There's a target reset bug.
      
      This loop:
      
      	for (id = 0; id <= shost->max_id; id++) {
      
      Never terminates if shost->max_id is set to ~0, like aic94xx does.
      
      It's also pretty inefficient since you mostly have compact target
      numbers, but the max_id can be very high.  The best way would be to
      sort the recovery list by target id and skip them if they're equal,
      but even a worst case O(N^2) traversal is probably OK here, so fix it
      by finding the next highest target number (assuming n+1) and
      terminating when there isn't one.
      
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      c82dc88d
    • M
      [SCSI] modify scsi to handle new fail fast flags. · 4a27446f
      Mike Christie 提交于
      This checks the errors the scsi-ml determined were retryable
      and returns if we should fast fail it based on the request
      fail fast flags.
      
      Without the patch, drivers like lpfc, qla2xxx and fcoe would return
      DID_ERROR for what it determines is a temporary communication problem.
      There is no loss of connectivity at that time and the driver thinks
      that it would be fast to retry at the driver level. SCSI-ml will however
      sees fast fail on the request and DID_ERROR and will fast fail the io.
      This will then cause dm-multipath to fail the path and possibley switch
      target controllers when we should be retrying at the scsi layer.
      
      We also were fast failing device errors to dm multiapth when
      unless the scsi_dh modules think otherwis we want to retry at
      the scsi layer because multipath can only retry the IO like scsi
      should have done. multipath is a little dumber though because it
      does not what the error was for and assumes that it should fail
      the paths.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      4a27446f
    • M
      [SCSI] scsi: add transport host byte errors (v3) · a4dfaa6f
      Mike Christie 提交于
      Currently, if there is a transport problem the iscsi drivers will return
      outstanding commands (commands being exeucted by the driver/fw/hw) with
      DID_BUS_BUSY and block the session so no new commands can be queued.
      Commands that are caught between the failure handling and blocking are
      failed with DID_IMM_RETRY or one of the scsi ml queuecommand return values.
      When the recovery_timeout fires, the iscsi drivers then fail IO with
      DID_NO_CONNECT.
      
      For fcp, some drivers will fail some outstanding IO (disk but possibly not
      tape) with DID_BUS_BUSY or DID_ERROR or some other value that causes a retry
      and hits the scsi_error.c failfast check, block the rport, and commands
      caught in the race are failed with DID_IMM_RETRY. Other drivers, may
      hold onto all IO and wait for the terminate_rport_io or dev_loss_tmo_callbk
      to be called.
      
      The following patches attempt to unify what upper layers will see drivers
      like multipath can make a good guess. This relies on drivers being
      hooked into their transport class.
      
      This first patch just defines two new host byte errors so drivers can
      return the same value for when a rport/session is blocked and for
      when the fast_io_fail_tmo fires.
      
      The idea is that if the LLD/class detects a problem and is going to block
      a rport/session, then if the LLD wants or must return the command to scsi-ml,
      then it can return it with DID_TRANSPORT_DISRUPTED. This will requeue
      the IO into the same scsi queue it came from, until the fast io fail timer
      fires and the class decides what to do.
      
      When using multipath and the fast_io_fail_tmo fires then the class
      can fail commands with DID_TRANSPORT_FAILFAST or drivers can use
      DID_TRANSPORT_FAILFAST in their terminate_rport_io callbacks or
      the equivlent in iscsi if we ever implement more advanced recovery methods.
      A LLD, like lpfc, could continue to return DID_ERROR and then it will hit
      the normal failfast path, so drivers do not have fully be ported to
      work better. The point of the patches is that upper layers will
      not see a failure that could be recovered from while the rport/session is
      blocked until fast_io_fail_tmo/recovery_timeout fires.
      
      V3
      Remove some comments.
      V2
      Fixed patch/diff errors and renamed DID_TRANSPORT_BLOCKED to
      DID_TRANSPORT_DISRUPTED.
      V1
      initial patch.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      a4dfaa6f
  3. 09 10月, 2008 1 次提交
  4. 29 8月, 2008 1 次提交
  5. 27 7月, 2008 4 次提交
  6. 05 6月, 2008 1 次提交
  7. 02 5月, 2008 1 次提交
    • B
      [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer · 64a87b24
      Boaz Harrosh 提交于
       - struct scsi_cmnd had a 16 bytes command buffer of its own.
         This is an unnecessary duplication and copy of request's
         cmd. It is probably left overs from the time that scsi_cmnd
         could function without a request attached. So clean that up.
      
       - Once above is done, few places, apart from scsi-ml, needed
         adjustments due to changing the data type of scsi_cmnd->cmnd.
      
       - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
         that #define but equate it to BLK_MAX_CDB. The way I see it
         and is reflected in the patch below is.
         MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                            as per the SCSI standard and is not related
                            to the implementation.
         BLK_MAX_CDB.     - The allocated space at the request level
      
       - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
         Operation. Same audit was done by Andi Kleen.
      
      (*)fixed-length here means commands that their size can be determined
         by their opcode and the CDB does not carry a length specifier, (unlike
         the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
         true and the SCSI standard also defines extended commands and
         vendor specific commands that can be bigger than 16 bytes. The kernel
         will support these using the same infrastructure used for VARLEN CDB's.
         So in effect MAX_COMMAND_SIZE means the maximum size command
         scsi-ml supports without specifying a cmd_len by ULD's
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      64a87b24
  8. 29 4月, 2008 1 次提交
  9. 08 4月, 2008 2 次提交
  10. 31 1月, 2008 2 次提交
    • B
      [SCSI] bidirectional command support · 6f9a35e2
      Boaz Harrosh 提交于
      At the block level bidi request uses req->next_rq pointer for a second
      bidi_read request.
      At Scsi-midlayer a second scsi_data_buffer structure is used for the
      bidi_read part. This bidi scsi_data_buffer is put on
      request->next_rq->special. Struct scsi_cmnd is not changed.
      
      - Define scsi_bidi_cmnd() to return true if it is a bidi request and a
        second sgtable was allocated.
      
      - Define scsi_in()/scsi_out() to return the in or out scsi_data_buffer
        from this command This API is to isolate users from the mechanics of
        bidi.
      
      - Define scsi_end_bidi_request() to do what scsi_end_request() does but
        for a bidi request. This is necessary because bidi commands are a bit
        tricky here. (See comments in body)
      
      - scsi_release_buffers() will also release the bidi_read scsi_data_buffer
      
      - scsi_io_completion() on bidi commands will now call
        scsi_end_bidi_request() and return.
      
      - The previous work done in scsi_init_io() is now done in a new
        scsi_init_sgtable() (which is 99% identical to old scsi_init_io())
        The new scsi_init_io() will call the above twice if needed also for
        the bidi_read command. Only at this point is a command bidi.
      
      - In scsi_error.c at scsi_eh_prep/restore_cmnd() make sure bidi-lld is not
        confused by a get-sense command that looks like bidi. This is done
        by puting NULL at request->next_rq, and restoring.
      
      [jejb: update to sg_table and resolve conflicts
      also update to blk-end-request and resolve conflicts]
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      6f9a35e2
    • B
      [SCSI] implement scsi_data_buffer · 30b0c37b
      Boaz Harrosh 提交于
      In preparation for bidi we abstract all IO members of scsi_cmnd,
      that will need to duplicate, into a substructure.
      
      - Group all IO members of scsi_cmnd into a scsi_data_buffer
        structure.
      - Adjust accessors to new members.
      - scsi_{alloc,free}_sgtable receive a scsi_data_buffer instead of
        scsi_cmnd. And work on it.
      - Adjust scsi_init_io() and  scsi_release_buffers() for above
        change.
      - Fix other parts of scsi_lib/scsi.c to members migration. Use
        accessors where appropriate.
      
      - fix Documentation about scsi_cmnd in scsi_host.h
      
      - scsi_error.c
        * Changed needed members of struct scsi_eh_save.
        * Careful considerations in scsi_eh_prep/restore_cmnd.
      
      - sd.c and sr.c
        * sd and sr would adjust IO size to align on device's block
          size so code needs to change once we move to scsi_data_buff
          implementation.
        * Convert code to use scsi_for_each_sg
        * Use data accessors where appropriate.
      
      - tgt: convert libsrp to use scsi_data_buffer
      
      - isd200: This driver still bangs on scsi_cmnd IO members,
        so need changing
      
      [jejb: rebased on top of sg_table patches fixed up conflicts
      and used the synergy to eliminate use_sg and sg_count]
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      30b0c37b
  11. 24 1月, 2008 1 次提交
  12. 12 1月, 2008 2 次提交
  13. 07 1月, 2008 1 次提交
    • L
      Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done"" · 7b3d9545
      Linus Torvalds 提交于
      This reverts commit ac40532e, which gets
      us back the original cleanup of 6f5391c2.
      
      It turns out that the bug that was triggered by that commit was
      apparently not actually triggered by that commit at all, and just the
      testing conditions had changed enough to make it appear to be due to it.
      
      The real problem seems to have been found by Peter Osterlund:
      
        "pktcdvd sets it [block device size] when opening the /dev/pktcdvd
         device, but when the drive is later opened as /dev/scd0, there is
         nothing that sets it back.  (Btw, 40944 is possible if the disk is a
         CDRW that was formatted with "cdrwtool -m 10236".)
      
         The problem is that pktcdvd opens the cd device in non-blocking mode
         when pktsetup is run, and doesn't close it again until pktsetup -d is
         run.  The effect is that if you meanwhile open the cd device,
         blkdev.c:do_open() doesn't call bd_set_size() because
         bdev->bd_openers is non-zero."
      
      In particular, to repeat the bug (regardless of whether commit
      6f5391c2 is applied or not):
      
        " 1. Start with an empty drive.
          2. pktsetup 0 /dev/scd0
          3. Insert a CD containing an isofs filesystem.
          4. mount /dev/pktcdvd/0 /mnt/tmp
          5. umount /mnt/tmp
          6. Press the eject button.
          7. Insert a DVD containing a non-writable filesystem.
          8. mount /dev/scd0 /mnt/tmp
          9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
          10. If the DVD contains data beyond the physical size of a CD, you
              get I/O errors in the terminal, and dmesg reports lots of
              "attempt to access beyond end of device" errors."
      
      which in turn is because the nested open after the media change won't
      cause the size to be set properly (because the original open still holds
      the block device, and we only do the bd_set_size() when we don't have
      other people holding the device open).
      
      The proper fix for that is probably to just do something like
      
      	bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
      
      in fs/block_dev.c:do_open() even for the cases where we're not the
      original opener (but *not* call bd_set_size(), since that will also
      change the block size of the device).
      
      Cc: Peter Osterlund <petero2@telia.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b3d9545
  14. 03 1月, 2008 1 次提交
  15. 18 10月, 2007 1 次提交
  16. 13 10月, 2007 6 次提交
  17. 18 7月, 2007 1 次提交
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  18. 24 5月, 2007 1 次提交
  19. 06 5月, 2007 1 次提交
    • B
      [SCSI] use sysfs configured timeout for EH Start Unit timeout · e555db93
      Brian King 提交于
      Use the sysfs configurable timeout when issuing a START_UNIT
      command from the scsi error handler. This is needed for devices which
      take longer than thirty seconds to respond to the start
      unit. The problem was observed when sending a start unit
      to a disk array device in an ipr RAID adapter, which results
      in the adapter firmware sending potentially multiple commands
      to physical devices as a result of this command, which ended
      up timing out sometimes. This patch does not change the default
      value used for this command.
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      e555db93
  20. 18 4月, 2007 1 次提交
    • B
      [SCSI] scsi_error.c: Add EH Start Unit retry · ed773e66
      Brian King 提交于
      Currently, the scsi error handler will issue a START_UNIT
      command if the drive indicates it needs its motor started
      and the allow_restart flag is set in the scsi_device. If,
      after the scsi error handler invokes a host adapter reset
      due to error recovery, a device is in a unit attention
      state AND also needs a START_UNIT, that device will be placed
      offline. The disk array devices on an ipr RAID adapter
      will do exactly this when in a dual initiator configuration.
      This patch adds a single retry to the EH initiated
      START_UNIT.
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      
      Patch modified and
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      ed773e66
  21. 03 4月, 2007 1 次提交
    • D
      [SCSI]: Fix scsi_send_eh_cmnd scatterlist handling · 8cc574a3
      David S. Miller 提交于
      This fixes a regression caused by commit:
      
      2dc611de
      
      The sense buffer code in scsi_send_eh_cmnd was changed to use
      alloc_page() and a scatter list, but the sense data copy was not
      updated to match so what we actually get in the sense buffer is total
      grabage starting with the kernel address of the struct page we got.
      Basically the stack frame of scsi_send_eh_cmd() is what ends up
      in the sense buffer.
      
      Depending upon how pointers look on a given platform, you can
      end up getting sr_ioctl.c errors when you mount a cdrom.  If
      the CDROM gives a check condition for GPCMD_GET_CONFIGURATION issued
      by drivers/cdrom/cdrom.c:cdrom_mmc_profile(), sr_ioctl will
      spit out this error message in sr_do_ioctl() with the way pointers
      are on sparc64:
      
      		default:
      			printk(KERN_ERR "%s: CDROM (ioctl) error, command: ", cd->cdi.name);
      			__scsi_print_command(cgc->cmd);
      			scsi_print_sense_hdr("sr", &sshdr);
      			err = -EIO;
      
      This is the error Tom Callaway reported in:
      
      http://marc.info/?l=linux-sparc&m=117407453208101&w=2
      
      Anyways, fix this by using page_address(sgl.page) which is OK
      because we know this is low-mem due to GFP_ATOMIC.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      8cc574a3
  22. 20 3月, 2007 1 次提交
  23. 03 2月, 2007 1 次提交
  24. 01 2月, 2007 1 次提交
  25. 28 1月, 2007 1 次提交
  26. 16 11月, 2006 1 次提交
  27. 11 10月, 2006 1 次提交