21 Apr, 2018
4 commits
-
On Fujitsu ETERNUS systems, sense code ABORTED COMMAND with ASC/Q C1/01
is used to indicate temporary condition where the storage-internal path
to a target is switched from one controller to another. SCSI commands
that return with this error code must be retried unconditionally
(i.e. without the "maybe_retry" logic in scsi_decide_disposition);
otherwise dm-multipath might initiate a failover from a healthy path
e.g. for REQ_FAILFAST_DEV commands.Introduce a new blist flag for this case.
[mkp: applied by hand]
Signed-off-by: Martin Wilck
Signed-off-by: Martin K. Petersen -
EMC Symmetrix returns 'internal target error' for a variety of
conditions, most of which will be transient. So we should always retry
it, even with failfast set. Otherwise we'd get spurious path flaps with
multipath.Signed-off-by: Martin Wilck
Signed-off-by: Martin K. Petersen -
Warn if a device (or the user) sets blist flags which are unknown
or have been removed. This should enable us to reuse freed blist
bits in later releases.Signed-off-by: Martin Wilck
Signed-off-by: Martin K. Petersen -
Space for SCSI blist flags is gradually running out. Change the type to
__u64 and fix a checkpatch complaint about symbolic mode flags in
scsi_devinfo.c.Make checkpatch happy by replacing simple_strtoul() with kstrtoull().
Signed-off-by: Martin Wilck
Signed-off-by: Martin K. Petersen
17 Nov, 2017
1 commit
-
As per recommendation from Linus we should be using a distinct type for
blacklist flags.[mkp: was cut against an older kernel, applied by hand]
Signed-off-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
15 Nov, 2017
1 commit
-
Pull SCSI updates from James Bottomley:
"This is mostly updates of the usual suspects: lpfc, qla2xxx, hisi_sas,
megaraid_sas, pm80xx, mpt3sas, be2iscsi, hpsa. and a host of minor
updates.There's no major behaviour change or additions to the core in all of
this, so the potential for regressions should be small (biggest
potential being in the scsi error handler changes)"* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (203 commits)
scsi: lpfc: Fix hard lock up NMI in els timeout handling.
scsi: mpt3sas: remove a stray KERN_INFO
scsi: mpt3sas: cleanup _scsih_pcie_enumeration_event()
scsi: aacraid: use timespec64 instead of timeval
scsi: scsi_transport_fc: add 64GBIT and 128GBIT port speed definitions
scsi: qla2xxx: Suppress a kernel complaint in qla_init_base_qpair()
scsi: mpt3sas: fix dma_addr_t casts
scsi: be2iscsi: Use kasprintf
scsi: storvsc: Avoid excessive host scan on controller change
scsi: lpfc: fix kzalloc-simple.cocci warnings
scsi: mpt3sas: Update mpt3sas driver version.
scsi: mpt3sas: Fix sparse warnings
scsi: mpt3sas: Fix nvme drives checking for tlr.
scsi: mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log info
scsi: mpt3sas: Add-Task-management-debug-info-for-NVMe-drives.
scsi: mpt3sas: scan and add nvme device after controller reset
scsi: mpt3sas: Set NVMe device queue depth as 128
scsi: mpt3sas: Handle NVMe PCIe device related events generated from firmware.
scsi: mpt3sas: API's to remove nvme drive from sml
scsi: mpt3sas: API 's to support NVMe drive addition to SML
...
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
17 Oct, 2017
1 commit
-
Reformat blacklist flags to make the values easier to read and to
enhance error checking.Signed-off-by: Hannes Reinecke
Reviewed-by: Bart van Assche
Reviewed-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
03 Oct, 2017
1 commit
-
SBC-4 states:
"A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
maximum number of LBAs that may be unmapped by an UNMAP command""A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
the maximum number of contiguous logical blocks that the device server
allows to be unmapped or written in a single WRITE SAME command."Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.Implement a blacklist option that can be used to accommodate devices
with this behavior.Cc:
Reported-by: Bill Kuzeja
Reported-by: Ewan D. Milne
Reviewed-by: Ewan D. Milne
Tested-by: Laurence Oberman
Signed-off-by: Martin K. Petersen
27 Jun, 2017
1 commit
-
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Signed-off-by: Martin K. Petersen
24 Feb, 2016
1 commit
-
Add a new blacklist flag BLIST_SYNC_ALUA to instruct the
alua device handler to use synchronous command submission
for ALUA commands.Reviewed-by: Bart Van Assche
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
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: 0and 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
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=79901Fixes: 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
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
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
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
24 Sep, 2012
1 commit
-
Hitachi Ultrastar 15K300 is quirky. Disable T10 PI (DIF).
Signed-off-by: Martin K. Petersen
Signed-off-by: James Bottomley
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
-
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
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
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!
