1. 18 Apr, 2006 7 commits
  2. 15 Apr, 2006 1 commit
  3. 14 Apr, 2006 12 commits
  4. 13 Apr, 2006 3 commits
    • James Smart's avatar
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      James Smart authored
      
      
      As previously reported via Michael Reed, the FC transport took a hit
      in 2.6.15 (perhaps a little earlier) when we solved a recursion error.
      There are 2 deadlocks occurring:
      - With scan and the delete items sharing the same workq, flushing the
        workq for the delete code was getting it stalled behind a very long
        running scan code path.
      - There's a deadlock where scsi_remove_target() has to sit behind
        scsi_scan_target() due to contention over the scan_lock().
      
      This patch resolves the 1st deadlock and significantly reduces the
      odds of the second. So far, we have only replicated the 2nd deadlock
      on a highly-parallel SMP system. More on the 2nd deadlock in a following
      email.
      
      This patch reworks the transport to:
      - Only use the scsi host workq for scanning
      - Use 2 other workq's internally. One for deletions, the other for
        scheduled deletions. Originally, we tried this with a single workq,
        but the occassional flushes of the scheduled queues was hitting the
        second deadlock with a slightly higher frequency. In the future, we'll
        look at the LLDD's and the transport to see if we can get rid of this
        extra overhead.
      - When moving to the other workq's we tightened up some object states
        and some lock handling.
      - Properly syncs adds/deletes
      - minor code cleanups
        - directly reference fc_host_attrs, rather than through attribute
          macros
        - flush the right workq on delayed work cancel failures.
      
      Large kudos to Michael Reed who has been working this issue for the last
      month.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      aedf3497
    • James Bottomley's avatar
      [SCSI] add SCSI_UNKNOWN and LUN transfer limit restrictions · 4d7db04a
      James Bottomley authored
      
      
      Original From: Ingo Flaschberger <if@xip.at>
      
      To support the RA4100 array from Compaq.
      
      This patch now correctly handles SCSI_UNKNOWN types with regard to
      BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't).
      
      It also allows a BLIST_MAX_512 flag to restrict the maximum transfer
      length to 512 blocks (apparently this is an RA4100 problem).
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4d7db04a
    • Christoph Hellwig's avatar
      [SCSI] unify SCSI_IOCTL_SEND_COMMAND implementations · 21b2f0c8
      Christoph Hellwig authored
      
      
      We currently have two implementations of this obsolete ioctl, one in
      the block layer and one in the scsi code.  Both of them have drawbacks.
      
      This patch kills the scsi layer version after updating the block version
      with the missing bits:
      
       - argument checking
       - use scatterlist I/O
       - set number of retries based on the submitted command
      
      This is the last user of non-S/G I/O except for the gdth driver, so
      getting this in ASAP and through the scsi tree would be nie to kill
      the non-S/G I/O path.  Jens, what do you think about adding a check
      for non-S/G I/O in the midlayer?
      
      Thanks to  Or Gerlitz for testing this patch.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      21b2f0c8
  5. 12 Apr, 2006 2 commits
  6. 11 Apr, 2006 15 commits