History log of /drivers/scsi/scsi_devinfo.c
Revision Date Author Comments
1899045510ff109980d9cc34e330fd8ca3631871 18-Nov-2014 Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de> scsi: add Intel Multi-Flex to scsi scan blacklist

Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES
resulting in sd_mod hanging for several minutes on startup.
The issue was introduced with WRITE SAME discovery heuristics.

Fixes: 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME")
Signed-off-by: Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
0213436a2cc5e4a5ca2fabfaa4d3877097f3b13f 24-Jul-2014 Janusz Dziemidowicz <rraptorr@nails.eu.org> scsi: do not issue SCSI RSOC command to Promise Vtrak E610f

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 <rraptorr@nails.eu.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
56f2a8016e0ab54de8daaac3df4712cad0fcef2e 25-Apr-2013 Martin K. Petersen <martin.petersen@oracle.com> [SCSI] Workaround for disks that report bad optimal transfer length

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 <snitzer@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
d974e4265dbd35db118c318176727ecb7f469de3 28-Aug-2012 Martin K. Petersen <martin.petersen@oracle.com> [SCSI] Disable DIF on Hitachi Ultrastar 15K300

Hitachi Ultrastar 15K300 is quirky. Disable T10 PI (DIF).

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
82103978189e9731658cd32da5eb85ab7b8542b8 09-Jun-2011 Werner Fink <werner@novell.com> [SCSI] Blacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups.

This patch resulted from the discussion at
https://bugzilla.novell.com/show_bug.cgi?id=679277,
https://bugzilla.novell.com/show_bug.cgi?id=681840 .

Signed-off-by: Werner Fink <werner@novell.com>
Signed-off-by: Ankit Jain <jankit@suse.de>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
38a039be2e7bda32517642ecfce54c9317292a9c 06-Jan-2011 Peter Jones <pjones@redhat.com> [SCSI] Add scsi_dev_info_list_del_keyed()

For scsi_dh.c to use devinfo lists, we have to be able to remove entries
before rmmod.

Signed-off-by: James Bottomley <James.Bottomley@suse.de>
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
1acf3b06f77a48b1607534408866473fb8018a65 17-Nov-2009 Randy Dunlap <randy.dunlap@oracle.com> [SCSI] fix func names in kernel-doc

Fix scsi_devinfo.c kernel-doc function names to match actual function
names.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
627511e3e67553b04f6917c03e39b797df210e04 10-Nov-2009 Takahiro Yasui <tyasui@redhat.com> [SCSI] scsi_devinfo: update Hitachi entries (v2)

Four models, OPEN-/DF400/DF500/DISK-SUBSYSTEM, can handle REPORT_LUN,
and the BLIST_REPORTLUN2 flag needs to be set. And DF600 doesn't require
any flags because it returns ANSI 03h (SPC).

Signed-off-by: Takahiro Yasui <tyasui@redhat.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
598fa4b775d064d4656132c78d9a312eb1d2f91f 17-Jun-2009 James Bottomley <James.Bottomley@HansenPartnership.com> enhance device info matching for multiple tables

The current scsi_devinfo.c matching routines use a single table for
the global blacklist. However, we're developing a need to blacklist
from specific transports too (notably some tape drives using SPI which
don't respond well to high speed protocols). Instead of developing
separate blacklist matching for each transport class needing it,
enhance the current list matching to permit multiple lists.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
4aa312b96f3220103e60c32740452a336dab6260 13-Jun-2009 James Bottomley <James.Bottomley@HansenPartnership.com> [SCSI] don't attach ULD to Dell Universal Xport

We already have blacklists for SGI, IBM and SUN versions of this; apparently
there's a Dell version too.

Reported-by: Thomas Witzel <witzel.thomas@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
99b76233803beab302123d243eea9e41149804f3 25-Mar-2009 Alexey Dobriyan <adobriyan@gmail.com> proc 2/2: remove struct proc_dir_entry::owner

Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
debf47779efd6eace440c884c8cca2665d966eb4 12-Jan-2009 ILLES, Marton <illes.marton@balabit.hu> [SCSI] Add SUN Universal Xport to no attach blacklist

I was using a Sun ST2510 device (iSCSI) and a special "block device"
appeared which is used by SUN Common Array Manager in-band management.

However it also appeared as a block device and caused some IO error:

[ 716.868000] scsi 15:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5
[ 716.868000] qla4xxx 0000:04:01.1: scsi(15:0:0:31): Enabled tagged queuing, queue depth 32.
[ 716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
[ 716.868000] sd 15:0:0:31: [sdf] Write Protect is off
[ 716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
[ 716.868000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
[ 716.868000] sd 15:0:0:31: [sdf] Write Protect is off
[ 716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
[ 716.872000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 716.872000] sdf: unknown partition table
[ 716.932000] sd 15:0:0:31: [sdf] Attached SCSI disk
[ 716.932000] sd 15:0:0:31: Attached scsi generic sg6 type 0
[ 717.412000] end_request: I/O error, dev sdf, sector 40
[ 717.412000] Buffer I/O error on device sdf, logical block 5
[ 717.412000] Buffer I/O error on device sdf, logical block 6
[ 717.412000] Buffer I/O error on device sdf, logical block 7
[ 717.412000] Buffer I/O error on device sdf, logical block 8
[ 717.412000] Buffer I/O error on device sdf, logical block 9
[ 717.412000] Buffer I/O error on device sdf, logical block 10
[ 717.412000] Buffer I/O error on device sdf, logical block 11
[ 717.412000] Buffer I/O error on device sdf, logical block 12
[ 717.412000] Buffer I/O error on device sdf, logical block 13
[ 717.412000] Buffer I/O error on device sdf, logical block 14

After some googling it appeared that similar issue has been solved for
SGI/IBM devices in 4869040512082b761de2d7c35975d01044f8bfea, so here is
the patch for SUN, please apply.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
cadbd4a5e36dde7e6c49b587b2c419103c0b7218 04-Jul-2008 Harvey Harrison <harvey.harrison@gmail.com> [SCSI] replace __FUNCTION__ with __func__

[jejb: fixed up a ton of missed conversions.

All of you are on notice this has happened, driver trees will now
need to be rebased]

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: SCSI List <linux-scsi@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
352ced8e594091d74b92da9bcf07aea81d37ac55 29-Apr-2008 Alexey Dobriyan <adobriyan@sw.ru> proc: switch /proc/scsi/device_info to seq_file interface

Note 1: 0644 should be used, but root bypasses permissions, so writing
to /proc/scsi/device_info still works.
Note 2: looks like scsi_dev_info_list is unprotected
Note 3: probably make proc whine about "unwriteable but with ->write hook"
entries. Probably.

Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
c93ff979a40e99f7229544cc8298c820b8eda17e 16-Nov-2007 Randy Dunlap <randy.dunlap@oracle.com> [SCSI] kernel-doc: use correct function name

Use correct function name in kernel-doc.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
eb44820c28bc9a042e1157b41c677018a8fdfc74 03-Nov-2007 Rob Landley <rob@landley.net> [SCSI] Add Documentation and integrate into docbook build

Add Documentation/DocBook/scsi_midlayer.tmpl, add to Makefile, and update
lots of kerneldoc comments in drivers/scsi/*.

Updated with comments from Stefan Richter, Stephen M. Cameron,
James Bottomley and Randy Dunlap.

Signed-off-by: Rob Landley <rob@landley.net>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2ffb45c672eff6a797712c5c8b5a6ddf3692187a 26-Jul-2007 Matthew Wilcox <matthew@wil.cx> [SCSI] Add QUANTUM XP34301 to the blacklist

According to the AdvanSys driver, this device has a problem with tagged
queueing.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
80b1c7bdc1cc69a804f416761f5faafcb6284086 27-Jul-2007 akpm@linux-foundation.org <akpm@linux-foundation.org> [SCSI] add easyRAID to the no report luns blacklist

According to http://bugzilla.kernel.org/show_bug.cgi?id=5953, the
easyRAID returns rubbish to REPORT LUNS.

Cc: Natalie Protasevich <protasnb@gmail.com>
Cc: Hans-Christian Armingeon <mog.johnny@gmx.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
80dc3e062a8f82acd5852df15f6b4bc3359de871 05-Jul-2007 Matthew Wilcox <matthew@wil.cx> [SCSI] Add Brownie 1200U3P to blacklist

The Brownie 1200U3P has the same problem with REPORT LUNS as the
1600U3P. Add it to the blacklist.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
e0b2e597d5dd8c4f3778545f65c29a9c6aba0e3a 10-May-2007 Ed Lin <ed.lin@promise.com> [SCSI] stex: fix id mapping issue

The correct internal mapping of stex controllers should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)

This patch reports the internal mapping to scsi mid layer, eliminating
the translation between scsi mid layer and firmware. To achieve this
goal, we also need to:
-- fail the REPORT_LUNS command for st_shasta because the
firmware is known to not report all actual luns
-- add an entry in scsi_devindo.c to force sequential lun scan
(for st_shasta controllers)
-- fail the REPORT_LUNS command for console device
-- remove special handling of REPORT_LUNS command for
st_yosemite, as there is no translation mapping now

Signed-off-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
f70cfa9bef432d7aeb4e35c093ac27fd6f071d7e 01-Oct-2006 Mike Christie <michaelc@cs.wisc.edu> [SCSI] scsi_devinfo: scsi2 HP and Hitachi entries

When SCSI-2 they can support luns past 7 and sparse luns.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
12427d99489966185dc12a0b6f725d682a3277ca 01-Oct-2006 Mike Christie <michaelc@cs.wisc.edu> [SCSI] scsi_devinfo: add nec iStorage

support the report luns opcode
.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
5f619c5ba509994c9203bfd18f5246b4457e2c22 01-Oct-2006 Mike Christie <michaelc@cs.wisc.edu> [SCSI] scsi_devinfo: add Tornado

This is from RHEL4. I do not have any info from our bugzilla. All
I could find was something like this thread
http://lkml.org/lkml/2005/1/7/346

Report lun for linux does not work. It may be our lun format code or
it may be the device. It is probably not worth it to add anything
special for this device, so the patch just adds BLIST_NOREPORTLUN.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
3441afc672bc9bfc137ae7717ac1db4b9c28cc8b 01-Oct-2006 Mike Christie <michaelc@cs.wisc.edu> [SCSI] scsi_devinfo: add EMC Invista

This is from RHEL4. This box can support
scsi2 and can also support BLIST_SPARSELUN | BLIST_LARGELUN.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
9ba0883cfc5ab69820c05f1bf2b7711bb0a0103c 22-Jun-2006 Hannes Reinecke <hare@suse.de> [SCSI] HP XP devinfo update

According to Anthony Cheung all HP XP arrays with "OPEN-"
types support REPORT_LUN. So there is no reason why we
shouldn't use it.

Signed-off-by: Anthony Cheung <anthony.cheung@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
c3d833685583f943fb0b5511a9e4602becb1668b 16-May-2006 Thomas Bogendoerfer <tsbogend@alpha.franken.de> [SCSI] Blacklist entry for HP dat changer

after upgrading our SUN E250 from 2.4 to 2.6 I'm seeing following error
when the HP DDS4 DAT changer gets probed:

scsi: host 1 channel 0 id 5 lun16777216 has a LUN larger than allowed by
the host adapter

The device is connected to a symbios 875 host. I've talked to Willy
about the problem, and he asked me to try to blacklist the device
for reportlun. I did that with the patch below and it solved the
problem. It now gets properly detected:

target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
Vendor: HP Model: C5713A Rev: H307
Type: Sequential-Access ANSI SCSI revision: 03
target1:0:5: Beginning Domain Validation
target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
target1:0:5: Domain Validation skipping write tests
target1:0:5: Ending Domain Validation
Vendor: HP Model: C5713A Rev: H307
Type: Medium Changer ANSI SCSI revision: 03

Signed-off-by: tsbogend@alpha.franken.de
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
f2536cbd12e5182558cce42efd41072bd558596b 26-Apr-2006 Brian King <brking@us.ibm.com> [SCSI] scsi: Add IBM 2104-DU3 to blist

Some versions of the IBM 2104-DU3 disk enclosure
have been observed to hang Inquiries to non zero
LUNs to the SES device. This device only has LUN 0,
so this patch adds it to the BLIST to prevent scsi
core from scanning beyond LUN 0.

Signed-off-by: Brian King <brking@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
13f7e5acc8b329080672c13f05f252ace5b79825 03-Apr-2006 Kurt Garloff <garloff@suse.de> [SCSI] BLIST_ATTACH_PQ3 flags

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 <garloff@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
4d7db04a7a69099accd84984a78c64d2178252f1 01-Apr-2006 James Bottomley <James.Bottomley@steeleye.com> [SCSI] add SCSI_UNKNOWN and LUN transfer limit restrictions

Original From: Ingo Flaschberger <if@xip.at>

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@SteelEye.com>
98acfc7e8e2606fadae6d2bf99fa040be917ce8c 01-Mar-2006 Matthew Wilcox <matthew@wil.cx> [SCSI] Add Brownie to blacklist

This device spews total rubbish to a REPORT LUNS command, so avoid
sending it one.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
7f23e146a122966bd58e5da9c16a0e12385f09fc 01-Dec-2005 James Bottomley <jejb@titanic.(none)> [SCSI] correct some dropped const compiler warnings

Make the vendor, model and rev fields in scsi_device pointers to const
and update a few prototypes of functions using them.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
f4fd20bf31376f29e4edde6596e3972198877309 17-Oct-2005 Karl Magnus Kolstoe <Karl.Kolsto@uib.no> [SCSI] 2.6.13.3; add Pioneer DRM-624x to drivers/scsi/scsi_devinfo.c

The patch below should make the Pioneer DRM-624X automatically
be set up with all 6 "drives". (6 slot SCSI CD changer)

Signed-off-by: Karl Magnus Kolst� <karl.kolsto@uib.no>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
1c5363153dc7ae694404e7732b4ce36eecc94ca7 12-Sep-2005 James Bottomley <James.Bottomley@steeleye.com> [SCSI] blacklist REPORT LUNS usage on transtec arrays

They report being SCSI-3 but seem to give back rubbish to a
REPORT_LUNS command. Force them to be sequentially scanned.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
4869040512082b761de2d7c35975d01044f8bfea 06-Sep-2005 Anton Blanchard <anton@samba.org> [SCSI] Universal Xport no attach blacklist

On Fri, Dec 13, 2002 at 12:24:39AM +1100, Anton Blanchard wrote:

> We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I
> had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management
> LUN was a disk:
>
> Vendor: IBM Model: Universal Xport Rev: 0520
> Type: Direct-Access ANSI SCSI revision: 03
>
> ...
>
> SCSI device sdaj: drive cache: write through
> SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB)
> sdaj: unknown partition table
> Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31
>
> ...
>
> end_request: I/O error, dev sdaj, sector 0

Three years later...

It looks like SGI use the same FC vendor and they already have a
workaround for this issue. The following patch adds the IBM version of
it.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
507caac75e86bd041c5462e5e988fb7138e21d79 09-Aug-2005 James Bottomley <jejb@mulgrave.(none)> [SCSI] Make the HSG80 a REPORTLUN2 device

From: Steve Wilcox <spwilcox@att.com>

In order to properly report LUN's > 7, the DEC HSG80 definition in
scsi_devinfo.c needs to include BLIST_REPORTLUN2 rather than
BLIST_SPARSELUN. I've tested this change with several HSG firmware
revisions and with both Emulex and Qlogic HBA's.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
0d7323c865608dffb1ed39ec2f3841697ec3e009 09-Aug-2005 Dave Jones <davej@redhat.com> [SCSI] blacklist addition.

When run on a kernel that scans all LUNs, a certain crappy
scsi scanner reports the same LUN over and over..
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155457

Aparently they were so shamed by this, they chose to remain
anonymous. Though it seems the blacklist code handles
anonymous vendors just fine.

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org> Linux-2.6.12-rc2

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!