1. 26 6月, 2006 1 次提交
    • L
      [SCSI] sd/scsi_lib simplify sd_rw_intr and scsi_io_completion · 03aba2f7
      Luben Tuikov 提交于
      This patch simplifies "good_bytes" computation in sd_rw_intr().
      sd: "good_bytes" computation is always done in terms of the resolution
      of the device's medium, since after that it is the number of good bytes
      we pass around and other layers/contexts (as opposed ot sd) can translate
      that to their own resolution (block layer:512).  It also makes
      scsi_io_completion() processing more straightforward, eliminating the
      3rd argument to the function.
      
      It also fixes a couple of bugs like not checking return value,
      using "break" instead of "return;", etc.
      
      I've been running with this patch for some time now on a
      test (do-it-all) system.
      Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      03aba2f7
  2. 11 6月, 2006 1 次提交
  3. 10 6月, 2006 1 次提交
  4. 01 6月, 2006 1 次提交
  5. 15 5月, 2006 1 次提交
    • T
      [PATCH] SCSI: implement shost->host_eh_scheduled · ee7863bc
      Tejun Heo 提交于
      libata needs to invoke EH without scmd.  This patch adds
      shost->host_eh_scheduled to implement such behavior.
      
      Currently the only user of this feature is libata and no general
      interface is defined.  This patch simply adds handling for
      host_eh_scheduled where needed and exports scsi_eh_wakeup() to
      modules.  The rest is upto libata.  This is the result of the
      following discussion.
      
      http://thread.gmane.org/gmane.linux.scsi/23853/focus=9760
      
      In short, SCSI host is not supposed to know about exceptions unrelated
      to specific device or command.  Such exceptions should be handled by
      transport layer proper.  However, the distinction is not essential to
      ATA and libata is planning to depart from SCSI, so, for the time
      being, libata will be using SCSI EH to handle such exceptions.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      ee7863bc
  6. 28 4月, 2006 1 次提交
    • J
      [SCSI] Fix DVD burning issues. · f3e93f73
      James Bottomley 提交于
      Some pioneer DVDs are apparently returning odd "not ready" status
      codes that the mid-layer doesn't recognise and so passes back to the
      user as errors.
      
      This patch overhauls our not-ready handling and adds transparent retries for:
      
      format in progress
      rebuild in progress
      recalculation in progress
      operation in progress
      Long write in progress
      self test in progress
      
      The Pioneer was actually returning "long write in progress"
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      f3e93f73
  7. 20 4月, 2006 1 次提交
  8. 15 4月, 2006 1 次提交
    • G
      [SCSI] dc395x: dynamically map scatter-gather for PIO · cdb8c2a6
      Guennadi Liakhovetski 提交于
      The current dc395x driver uses PIO to transfer up to 4 bytes which do not
      get transferred by DMA (under unclear circumstances). For this the driver
      uses page_address() which is broken on highmem. Apart from this the
      actual calculation of the virtual address is wrong (even without highmem).
      So, e.g., for reading it reads bytes from the driver to a wrong address
      and returns wrong data, I guess, for writing it would just output random
      data to the device.
      
      The proper fix, as suggested by many, is to dynamically map data using
      kmap_atomic(page, KM_BIO_SRC_IRQ) / kunmap_atomic(virt). The reason why it
      has not been done until now, although I've done some preliminary patches
      more than a year ago was that nobody interested in fixing this problem was
      able to reliably reproduce it. Now it changed - with the help from
      Sebastian Frei (CC'ed) I was able to trigger the PIO path. Thus, I was
      also able to test and debug it.
      
      There are 4 cases when PIO is used in dc395x - data-in / -out with and
      without scatter-gather. I was able to reproduce and test only data-in with
      and without SG. So, the data-out path is still untested, but it is also
      somewhat simpler than the data-in. Fredrik Roubert (also CC'ed) also had
      PIO triggering on his system, and in his case it was data-out without SG.
      It would be great if he could test the attached patch on his system, but
      even if he cannot, I would still request to apply the patch and just wait
      if anybody cries...
      
      Implementation: I put 2 new functions in scsi_lib.c and their declarations
      in scsi_cmnd.h. I exported them without _GPL, although, I don't feel
      strongly about that - not many drivers are likely to use them. But there
      is at least one more - I want to use them in tmscsim.c. Whether these are
      the right files for the functions and their declarations - not sure
      either. Actually, they are not scsi-specific, so, might go somewhere
      around other scattergather magic? They are not platform specific either,
      and most SG functions are defined under arch/*/... As these issues were
      discussed previously there were some more routines suggested to manipulate
      scattergather buffers, I think, some of them were needed around
      crypto code... So, might be a common place reasonable, like
      lib/scattergather.c? I am open here.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      cdb8c2a6
  9. 14 4月, 2006 1 次提交
  10. 27 3月, 2006 1 次提交
  11. 20 3月, 2006 1 次提交
  12. 28 2月, 2006 4 次提交
  13. 15 2月, 2006 1 次提交
    • J
      [PATCH] add scsi_execute_in_process_context() API · faead26d
      James Bottomley 提交于
      We have several points in the SCSI stack (primarily for our device
      functions) where we need to guarantee process context, but (given the
      place where the last reference was released) we cannot guarantee this.
      
      This API gets around the issue by executing the function directly if
      the caller has process context, but scheduling a workqueue to execute
      in process context if the caller doesn't have it.  Unfortunately, it
      requires memory allocation in interrupt context, but it's better than
      what we have previously.  The true solution will require a bit of
      re-engineering, so isn't appropriate for 2.6.16.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      faead26d
  14. 27 1月, 2006 1 次提交
    • B
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com 提交于
      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: NBrian King <brking@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      bb1d1073
  15. 15 1月, 2006 1 次提交
  16. 09 1月, 2006 1 次提交
  17. 06 1月, 2006 3 次提交
  18. 16 12月, 2005 2 次提交
    • J
      Fix up SCSI mismerge · 7b16318d
      James Bottomley 提交于
      I forgot to do a git-update-cache on the merged files ...
      7b16318d
    • M
      [SCSI] seperate max_sectors from max_hw_sectors · defd94b7
      Mike Christie 提交于
      - export __blk_put_request and blk_execute_rq_nowait
      needed for async REQ_BLOCK_PC requests
      - seperate max_hw_sectors and max_sectors for block/scsi_ioctl.c and
      SG_IO bio.c helpers per Jens's last comments. Since block/scsi_ioctl.c SG_IO was
      already testing against max_sectors and SCSI-ml was setting max_sectors and
      max_hw_sectors to the same value this does not change any scsi SG_IO behavior. It only
      prepares ll_rw_blk.c, scsi_ioctl.c and bio.c for when SCSI-ml begins to set
      a valid max_hw_sectors for all LLDs. Today if a LLD does not set it
      SCSI-ml sets it to a safe default and some LLDs set it to a artificial low
      value to overcome memory and feedback issues.
      
      Note: Since we now cap max_sectors to BLK_DEF_MAX_SECTORS, which is 1024,
      drivers that used to call blk_queue_max_sectors with a large value of
      max_sectors will now see the fs requests capped to BLK_DEF_MAX_SECTORS.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      defd94b7
  19. 15 12月, 2005 4 次提交
  20. 14 12月, 2005 2 次提交
  21. 13 12月, 2005 1 次提交
    • L
      Revert revert of "[SCSI] fix usb storage oops" · 49d7bc64
      Linus Torvalds 提交于
      This reverts commit 1b0997f5, which in
      turn reverted 34ea80ec (which is thus
      re-instated).
      
      Quoth James Bottomley:
      
        "All it's doing is deferring the device_put() from the
         scsi_put_command() to after the scsi_run_queue(), which doesn't fix
         the sleep while atomic problem of the device release method.  In both
         cases we still get the semaphore in atomic context problem which is
         caused by scsi_reap_target() doing a device_del(), which I assumed
         (wrongly) was valid from atomic context."
      
      who also promised to fix scsi_reap_target().
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      49d7bc64
  22. 10 12月, 2005 1 次提交
  23. 03 12月, 2005 1 次提交
  24. 09 11月, 2005 1 次提交
    • G
      [SCSI] fix usb storage oops · 34ea80ec
      goggin, edward 提交于
      The problem is that scsi_run_queue is called from scsi_next_command()
      after doing a scsi_put_command.  If the command was the only thing
      holding the reference on the scsi_device then the resulting device put
      will tear down the block queue.  Fix this by taking a reference to the
      device and holding it around scsi_run_queue()
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      34ea80ec
  25. 07 11月, 2005 1 次提交
  26. 29 10月, 2005 2 次提交
  27. 28 10月, 2005 1 次提交
  28. 17 10月, 2005 1 次提交
  29. 19 9月, 2005 1 次提交