1. 31 1月, 2008 1 次提交
  2. 28 1月, 2008 1 次提交
  3. 24 1月, 2008 1 次提交
  4. 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
  5. 03 1月, 2008 1 次提交
  6. 16 10月, 2007 4 次提交
  7. 13 10月, 2007 2 次提交
  8. 27 5月, 2007 1 次提交
  9. 12 3月, 2007 1 次提交
    • M
      [SCSI] tgt: rm bio hacks in scsi tgt · 181011e0
      Mike Christie 提交于
      scsi tgt breaks up a command into multple scatterlists
      if we cannot fit all the data in one. This was because
      the block rq helpers did not support large requests and
      because we can get a command of any old size so it is
      hard to preallocate pages for scatterlist large enough
      (we cannot really preallocate pages with the bio map
      user path). In 2.6.20, we added large request support to
      the block layer helper, blk_rq_map_user. And at LSF,
      we talked about increasing SCSI_MAX_PHYS_SEGMENTS for
      scsi tgt if we want to support really really :) large
      (greater than 256 * PAGE_SIZE in the worst mapping case)
      requests.
      
      The only target currently implemented does not even support
      the multiple scatterlists stuff and only supports smaller
      requests, so this patch just coverts scsi tgt to use
      blk_rq_map_user.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      181011e0
  10. 26 11月, 2006 1 次提交
    • F
      [SCSI] export scsi-ml functions needed by tgt_scsi_lib and its LLDs · b58d9154
      FUJITA Tomonori 提交于
      This patch contains the needed changes to the scsi-ml for the target
      mode support.
      
      Note, per the last review we moved almost all the fields we added
      to the scsi_cmnd to our internal data structure which we are going
      to try and kill off when we can replace it with support from other
      parts of the kernel.
      
      The one field we left on was the offset variable. This is needed to handle
      the case where the target gets request that is so large that it cannot
      execute it in one dma operation. So max_secotors or a segment limit may
      limit the size of the transfer. In this case our tgt core code will
      break up the command into managable transfers and send them to the
      LLD one at a time. The offset is then used to tell the LLD where in
      the command we are at. Is there another field on the scsi_cmd for
      that?
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b58d9154
  11. 07 8月, 2006 1 次提交
  12. 10 7月, 2006 1 次提交
    • C
      [SCSI] hide EH backup data outside the scsi_cmnd · 631c228c
      Christoph Hellwig 提交于
      Currently struct scsi_cmnd has various fields that are used to backup
      original data after the corresponding fields have been overridden for
      EH commands.  This means drivers can easily get at it and misuse it.
      Due to the old_ naming this doesn't happen for most of them, but two
      that have different names have been used wrong a lot (see previous
      patch).  Another downside is that they unessecarily bloat the scsi_cmnd
      size.
      
      This patch moves them onstack in scsi_send_eh_cmnd to fix those two
      issues aswell as allowing future EH fixes like moving the EH command
      submissions to use SG lists like everything else.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      631c228c
  13. 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
  14. 11 6月, 2006 1 次提交
  15. 15 5月, 2006 1 次提交
  16. 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
  17. 28 2月, 2006 1 次提交
  18. 15 1月, 2006 1 次提交
  19. 16 12月, 2005 1 次提交
  20. 14 12月, 2005 1 次提交
  21. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      Tim Schmielau 提交于
      I recently picked up my older work to remove unnecessary #includes of
      sched.h, starting from a patch by Dave Jones to not include sched.h
      from module.h. This reduces the number of indirect includes of sched.h
      by ~300. Another ~400 pointless direct includes can be removed after
      this disentangling (patch to follow later).
      However, quite a few indirect includes need to be fixed up for this.
      
      In order to feed the patches through -mm with as little disturbance as
      possible, I've split out the fixes I accumulated up to now (complete for
      i386 and x86_64, more archs to follow later) and post them before the real
      patch.  This way this large part of the patch is kept simple with only
      adding #includes, and all hunks are independent of each other.  So if any
      hunk rejects or gets in the way of other patches, just drop it.  My scripts
      will pick it up again in the next round.
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  22. 28 10月, 2005 1 次提交
  23. 08 8月, 2005 1 次提交
    • J
      [SCSI] add global timeout to the scsi mid-layer · b21a4138
      James Bottomley 提交于
      There are certain rogue devices (and the aic7xxx driver) that return
      BUSY or QUEUE_FULL forever.  This code will apply a global timeout (of
      the total number of retries times the per command timer) to a given
      command.  If it is exceeded, the command is completed regardless of its
      state.
      
      The patch also removes the unused field in the command: timeout and
      timeout_total.
      
      This solves the problem of detecting an endless loop in the mid-layer
      because of BUSY/QUEUE_FULL bouncing, but will not recover the device.
      In the aic7xxx case, the driver can be recovered by sending a bus reset,
      so possibly this should be tied into the error handler?
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b21a4138
  24. 27 6月, 2005 4 次提交
  25. 19 4月, 2005 2 次提交
  26. 17 4月, 2005 3 次提交