1. 23 Feb, 2016 1 commit
  2. 27 Apr, 2015 1 commit
    • Mike Christie's avatar
      SCSI: add 1024 max sectors black list flag · 35e9a9f9
      Mike Christie authored
      This works around a issue with qnap iscsi targets not handling large IOs
      very well.
      The target returns:
      VPD INQUIRY: Block limits page (SBC)
        Maximum compare and write length: 1 blocks
        Optimal transfer length granularity: 1 blocks
        Maximum transfer length: 4294967295 blocks
        Optimal transfer length: 4294967295 blocks
        Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
        Maximum unmap LBA count: 8388607
        Maximum unmap block descriptor count: 1
        Optimal unmap granularity: 16383
        Unmap granularity alignment valid: 0
        Unmap granularity alignment: 0
        Maximum write same length: 0xffffffff blocks
        Maximum atomic transfer length: 0
        Atomic alignment: 0
        Atomic transfer length granularity: 0
      and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
      have seen in traces where it will sometimes work, but other times it
      looks like it fails and it looks like it returns failures if we send
      multiple large IOs sometimes. Also it looks like it can return 2 different
      errors. It will sometimes send iscsi reject errors indicating out of
      resources or it will send invalid cdb illegal requests check conditions.
      And then when it sends iscsi rejects it does not seem to handle retries
      when there are command sequence holes, so I could not just add code to
      try and gracefully handle that error code.
      The problem is that we do not have a good contact for the company,
      so we are not able to determine under what conditions it returns
      which error and why it sometimes works.
      So, this patch just adds a new black list flag to set targets like this to
      the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
      caused this regression, so I also ccing stable.
      Reported-by: default avatarChristian Hesse <list@eworm.de>
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
  3. 29 Jul, 2014 1 commit
  4. 25 Jul, 2014 1 commit
  5. 17 Jul, 2014 1 commit
  6. 24 Jun, 2013 1 commit
  7. 24 Sep, 2012 1 commit
  8. 14 Apr, 2006 1 commit
    • Kurt Garloff's avatar
      [SCSI] BLIST_ATTACH_PQ3 flags · 13f7e5ac
      Kurt Garloff authored
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      This is patch 3/3:
      3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
         scanning code register PQ3 devices and continues scanning; only sg
         will attach thanks to scsi_bus_match().
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  9. 13 Apr, 2006 1 commit
  10. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!