Commit Graph

31 Commits

Author SHA1 Message Date
James Bottomley 598fa4b775 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>
2009-06-21 10:52:45 -05:00
James Bottomley 4aa312b96f [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>
2009-06-15 10:09:34 -05:00
Alexey Dobriyan 99b7623380 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>
2009-03-31 01:14:44 +04:00
ILLES, Marton debf47779e [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 4869040512, so here is
the patch for SUN, please apply.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-01-13 10:45:44 -06:00
Harvey Harrison cadbd4a5e3 [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>
2008-07-27 10:31:49 -04:00
Alexey Dobriyan 352ced8e59 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>
2008-04-29 08:06:19 -07:00
Randy Dunlap c93ff979a4 [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>
2008-01-11 18:22:44 -06:00
Rob Landley eb44820c28 [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>
2008-01-11 18:22:40 -06:00
Matthew Wilcox 2ffb45c672 [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>
2007-10-12 14:39:19 -04:00
akpm@linux-foundation.org 80b1c7bdc1 [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>
2007-07-28 10:00:28 -04:00
Matthew Wilcox 80dc3e062a [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>
2007-07-14 18:58:37 -05:00
Ed Lin e0b2e597d5 [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>
2007-05-16 12:40:21 -04:00
Mike Christie f70cfa9bef [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>
2006-10-01 15:09:19 -05:00
Mike Christie 12427d9948 [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>
2006-10-01 15:08:41 -05:00
Mike Christie 5f619c5ba5 [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>
2006-10-01 15:07:57 -05:00
Mike Christie 3441afc672 [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>
2006-10-01 15:07:11 -05:00
Hannes Reinecke 9ba0883cfc [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>
2006-06-26 09:30:00 -05:00
James Bottomley f0cd91a68a Merge ../linux-2.6 2006-06-10 13:47:26 -05:00
Thomas Bogendoerfer c3d8336855 [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>
2006-05-19 16:41:20 -05:00
Brian King f2536cbd12 [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>
2006-04-27 13:59:05 -05:00
James Bottomley 84d891d672 Merge ../scsi-rc-fixes-2.6
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@SteelEye.com>
2006-04-14 15:47:45 -05:00
Kurt Garloff 13f7e5acc8 [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>
2006-04-14 13:56:56 -05:00
James Bottomley 4d7db04a7a [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>
2006-04-13 10:13:31 -05:00
Matthew Wilcox 98acfc7e8e [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>
2006-03-02 22:44:06 -06:00
James Bottomley 7f23e146a1 [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>
2005-12-13 18:12:05 -07:00
Karl Magnus Kolstoe f4fd20bf31 [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>
2005-10-17 12:24:04 -04:00
James Bottomley 1c5363153d [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>
2005-09-13 09:52:19 -05:00
Anton Blanchard 4869040512 [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>
2005-09-06 17:23:43 -05:00
James Bottomley 507caac75e [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>
2005-08-12 11:40:50 -05:00
Dave Jones 0d7323c865 [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>
2005-08-08 18:08:45 -05:00
Linus Torvalds 1da177e4c3 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!
2005-04-16 15:20:36 -07:00