24 Feb, 2016

1 commit


28 Apr, 2015

1 commit

  • 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: Christian Hesse
    Signed-off-by: Mike Christie
    Cc: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig
    Signed-off-by: James Bottomley

    Mike Christie
     

30 Jul, 2014

1 commit

  • Some devices don't like REPORT SUPPORTED OPERATION CODES and will
    simply timeout causing sd_mod init to take a very very long time.
    Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being
    issued. Add it to Promise Vtrak E610f entry in scsi scan
    blacklist. Fixes bug #79901 reported at
    https://bugzilla.kernel.org/show_bug.cgi?id=79901

    Fixes: 98dcc2946adb ("SCSI: sd: Update WRITE SAME heuristics")

    Signed-off-by: Janusz Dziemidowicz
    Reviewed-by: Martin K. Petersen
    Cc: stable@vger.kernel.org
    Signed-off-by: Christoph Hellwig

    Janusz Dziemidowicz
     

26 Jul, 2014

1 commit

  • Despite supporting modern SCSI features some storage devices continue to
    claim conformance to an older version of the SPC spec. This is done for
    compatibility with legacy operating systems.

    Linux by default will not attempt to read VPD pages on devices that
    claim SPC-2 or older. Introduce a blacklist flag that can be used to
    trigger VPD page inquiries on devices that are known to support them.

    Reported-by: KY Srinivasan
    Tested-by: KY Srinivasan
    Reviewed-by: KY Srinivasan
    Signed-off-by: Martin K. Petersen
    CC:
    Signed-off-by: Christoph Hellwig

    Martin K. Petersen
     

18 Jul, 2014

1 commit

  • Sequential scan for more than 256 LUNs is very fragile as
    LUNs might not be numbered sequentially after that point.

    SAM revisions later than SCSI-3 impose a structure on
    LUNs larger than 256, making LUN numbers between 256
    and 16384 illegal.
    SCSI-3, however allows for plain 64-bit numbers with
    no internal structure.

    So restrict sequential LUN scan to 256 LUNs and add a
    new blacklist flag 'BLIST_SCSI3LUN' to scan up to
    max_lun devices.

    Signed-off-by: Hannes Reinecke
    Reviewed-by: Ewan Milne
    Signed-off-by: Christoph Hellwig

    Hannes Reinecke
     

25 Jun, 2013

1 commit

  • Not all disks fill out the VPD pages correctly. Add a blacklist flag
    that allows us ignore the SBC-3 VPD pages for a given device. The
    BLIST_SKIP_VPD_PAGES flag triggers our existing skip_vpd_pages
    scsi_device parameter to bypass VPD scanning.

    Also blacklist the offending Seagate drive model.

    Reported-by: Mike Snitzer
    Signed-off-by: Martin K. Petersen
    Signed-off-by: James Bottomley

    Martin K. Petersen
     

24 Sep, 2012

1 commit


15 Apr, 2006

2 commits

  • Conflicts:

    include/scsi/scsi_devinfo.h

    Same number for two BLIST flags: BLIST_MAX_512 and BLIST_ATTACH_PQ3

    Signed-off-by: James Bottomley

    James Bottomley
     
  • 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: Kurt Garloff
    Signed-off-by: James Bottomley

    Kurt Garloff
     

13 Apr, 2006

1 commit

  • Original From: Ingo Flaschberger

    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: James Bottomley

    James Bottomley
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds