SCSI updates for 2.6.6

This is the latest set of assorted fixes, plus one new driver: the IBM Power Raid (ipr).

The patch can be pulled from:

bk://linux-scsi.bkbits.net/scsi-for-linus-2.6

The short changelog is:

<aradford:amcc.com>:
o 3ware driver update

<noodles:earth.li>:
o Initio INI-9X00U/UW error handling in 2.6

<praka:users.sourceforge.net>:
o qla2xxx set current state fixes

Alan Stern:
o (as255) Handle Unit Attention during INQUIRY better

Andrew Morton:
o aic7xxx deadlock fix
o scsi_disk_release() warning fix

Andrew Vasquez:
o qla2100 fabric fixes
o [15/15] qla2xxx: Update driver version
o [14/15] qla2xxx: Resync with latest released firmware -- 3.02.28
o [13/15] qla2xxx: Misc. code scrubbing
o [12/15] qla2xxx: RIO/ZIO fixes
o [11/15] qla2xxx: /proc fixes
o [10/15] qla2xxx: Use readX_relaxed

  o [9/15]  qla2xxx: Tape command handling fixes
  o [8/15]  qla2xxx: Volatile topology fixes
  o [7/15]  qla2xxx: Firmware options fixes
  o [6/15]  qla2xxx: LoopID downcast fix
  o [5/15]  qla2xxx: Debug messages during ISP abort
  o [4/15]  qla2xxx: PortID binding fixes
  o [3/15]  qla2xxx: 2100 request-q contraints
  o [2/15]  qla2xxx: Remove flash routines
  o [1/15]  qla2xxx: Firmware dump fixes

Aristeu Sergio Rozanski Filho:
o qlogic_cs: use qlogicfas408 module
o qlogicfas: split and create a new module
o qlogicfas: kill horrible irq probing

Bob Tracy:
o sym53c500_cs remove irq,ioport scsi attributes
o sym53c500_cs PCMCIA SCSI driver (round 5)

Brian King:
o Add IBM power RAID driver 2.0.6
o Make SCSI timeout modifiable

Chris Wright:
o Update aacraid MAINTAINERS entry

Christoph Hellwig:
o mca_53c9x needs CONFIG_MCA_LEGACY
o missing pci_set_master in megaraid
o imm/ppa style police

Eric Dean Moore:
o MPT Fusion driver 3.01.06 update
o MPT Fusion add back FC909 support

Herbert Xu:
o aic7xxx: fix oops whe hardware is not present

James Bottomley:
o fix LLD module refcounting in sr.c
o Add SCSI IPR PCI Ids to pci_ids.h
o Fix errors in [PATCH] aic7xxx: fix oops whe hardware is not present

  o Cset exclude: jejb@mulgrave.(none)|ChangeSet|20040404150128|05866

o aic7xxx: compile fix for EISA only case

Jeremy Higdon:
o minor changes to qla1280 driver

Kai Mäkisara:
o SCSI tape log message fixes

Kurt Garloff:
o scsi: don't attach device if PQ indicates not connected

Mark Haverkamp:
o aacraid reset handler fix

Michael Veeck:
o (3/5) ncr53c8x: use kernel.h min/max
o (4/5) nsp32 (ninja): use kernel.h min/max/ARRAY_SIZE
o (2/5) aic7xyz_old: use kernel.h min/max/ARRAY_SIZE
o (5/5) pcmcia/nsp: use kernel.h min/max/ARRAY_SIZE

Mike Anderson:
o fix module unload problem in sd

Pavel Machek:
o support swsusp for aic7xxx

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi James,

Should I resubmit the other SCSI scanning/blacklist patches or are they queued? Or rejected?

Regards,

Kurt Garloff  <[email protected]>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

I thought' I'd put in all the necessary ones, what's missing?

James

Hi James,

sorry for the late response.

(0) scsi-log-unlikely
Add unlikely to SCSI_CHECK_LOGGING() macro
(1) scsi-scan-deprecate-forcelun
Mark BLIST_FORCELUN as deprecated; it should not be used. Don't discourage CONFIG_SCSI_MULTI_LUN so strongly. (Actually I believe it should always be switched on and
people with completely broken hardware should get it blacklisted rather than "black"listing perfectly working devices. max_luns=1 can still be used to override it, but, for some reason there was no agreement about this on LSML, so I agreed on merging the patch as is ...)
(2) scsi-scan-blist_replun
Introduce blacklist flags BLIST_NOREPORTLUN and BLIST_REPORTLUN2, so the use of REPORT_LUNS can turned off by passing dev_flags for a device or by default_dev_flags globally. The other flag allows to explicitly ask the kernel to try REPORT_LUNS on SCSI-2 devices as well (normally it only uses it for SCSI-3 devices) if the host adapter does support more than 8 LUNs. This is mostly for RAIDs that are connected via FC (which supports more than 8 LUNs unlike SPI) that report as SCSI-2, so this flag can often be turned on. Just look at all the devices with BLIST_SPARSELUN | BLIST_LARGELUN. Could all be nuked on the long term ...
The CONFIG_SCSI_REPORT_LUNS option is killed by this patch.
(3) scsi-scan-no-offl-pq-notcon
Don't set devices to offline if the Periph Qual is non-zero. Instead don't connect to them from highlevel drivers except for sg.
(4) scsi-scan-inq-timeout
Make the inquiry timeout configurable by boot/module parameter; there are some sick devices out there who need >20s to recover from a bus reset; we obviously don't want to bump the default to 25s because of that sickness.

Only patch 3 can be found in 2.6.6.

Patch 0 should be a no-brainer.
It allows vendors to enable CONFIG_SCSI_LOGGING
without incurring possibly mispredicted branches.

Patch 1 should go in; so we announce that the insanity of blacklisting perfectly fine SCSI devices will stop at some point in the future (2.7.)

Patch 2 should go in; a config option is only useful for people compiling their own kernels, i.e. developers. Thus there should be the possibility to influence the use of REPORT_LUNS at boot or runtime. Meanwhile the conflicting BLIST_MS_192_BYTES_FOR_3F has been defined, which is less than optimal. The patch would need to be rediffed and non-conflicting constants be used.

Patch 4 should go in; it allows users to work around sick SCSI devices without needing to create crazy defaults.

All of these patches live in the SUSE Enterprise kernel and were introduced because there was a need for them when supporting customers.

All patches have been discussed extensively on LSML and were changed until opposition vanished.

If wanted, I can rediff and resubmit.

Regards,

Kurt Garloff  <[email protected]>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                        Director SUSE Labs

Patches against 2.6.6 attached.

Regards,

Kurt Garloff  <[email protected]>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                        Director SUSE Labs

[email protected]

Optimization.

Tell the compiler that the SCSI LOG will not likely happen.

@@ -46,7 +46,7 @@ extern unsigned int scsi_logging_level;
 
 #define SCSI_CHECK_LOGGING(SHIFT, BITS, LEVEL, CMD)		\
 {								\
-        if ((SCSI_LOG_LEVEL(SHIFT, BITS)) > (LEVEL))		\
+        if (unlikely((SCSI_LOG_LEVEL(SHIFT, BITS)) > (LEVEL)))	\
 		(CMD);						\
 }
 #else

[email protected]

Cleanup

Mark BLIST_FORCELUN as deprecated, as we don't want to collect a list of perfectly working multi-LUN devices with BLIST_FORCELUN. Instead document max_luns boot/module parameter.

diff -uNrp linux-2.6.5.scsi-orig/drivers/scsi/Kconfig linux-2.6.5.depr-forcelun/drivers/scsi/Kconfig
@@ -167,8 +167,8 @@ config SCSI_MULTI_LUN
 	  can say Y here to force the SCSI driver to probe for multiple LUNs.
 	  A SCSI device with multiple LUNs acts logically like multiple SCSI
 	  devices. The vast majority of SCSI devices have only one LUN, and
-	  so most people can say N here and should in fact do so, because it
-	  is safer.
+	  so most people can say N here. The max_luns boot/module parameter 
+	  allows to override this setting.
 
 config SCSI_REPORT_LUNS
 	bool "Build with SCSI REPORT LUNS support"

diff -uNrp linux-2.6.5.scsi-orig/include/scsi/scsi_devinfo.h linux-2.6.5.depr-forcelun/include/scsi/scsi_devinfo.h
@@ -4,7 +4,8 @@
  * Flags for SCSI devices that need special treatment
  */
 #define BLIST_NOLUN     	0x001	/* Only scan LUN 0 */
-#define BLIST_FORCELUN  	0x002	/* Known to have LUNs, force scanning */
+#define BLIST_FORCELUN  	0x002	/* Known to have LUNs, force scanning,
+					   deprecated: Use max_luns=N */
 #define BLIST_BORKEN    	0x004	/* Flag for broken handshaking */
 #define BLIST_KEY       	0x008	/* unlock by special command */
 #define BLIST_SINGLELUN 	0x010	/* Do not use LUNs in parallel */

[email protected]

Cleanup/Feature

Remove CONFIG_SCSI_REPORT_LUNS config option.
Instead provide BLIST_NOREPORTLUN that can be passed as default_dev_flags (but also per device if needed).
Provide BLIST_REPORTLUN2 that allows trying to use REPORT_LUNS for SCSI-2 devices, if they are connected to a host adapter supporting more than 8 LUNs (and thus avoiding the usual USB crap to render this feature useless when used with default_dev_flags).

 drivers/scsi/Kconfig        |   11 -----------
 drivers/scsi/scsi_scan.c    |   19 +++++++++----------
 include/scsi/scsi_devinfo.h |    3 +++
 3 files changed, 12 insertions(+), 21 deletions(-)

diff -uNrp linux-2.6.5/drivers/scsi/Kconfig linux-2.6.5.scsi-replun/drivers/scsi/Kconfig
@@ -170,17 +170,6 @@ config SCSI_MULTI_LUN
 	  so most people can say N here. The max_luns boot/module parameter 
 	  allows to override this setting.
 
-config SCSI_REPORT_LUNS
-	bool "Build with SCSI REPORT LUNS support"
-	depends on SCSI
-	default y
-	help
-	  If you want support for SCSI REPORT LUNS, say Y here.
-	  The REPORT LUNS command is useful for devices (such as disk arrays)
-	  with large numbers of LUNs where the LUN values are not contiguous
-	  (sparse LUN).  REPORT LUNS scanning is done only for SCSI-3 devices.
-	  Most users can safely answer N here.
-
 config SCSI_CONSTANTS
 	bool "Verbose SCSI error reporting (kernel size +=12K)"
 	depends on SCSI

diff -uNrp linux-2.6.5/drivers/scsi/scsi_scan.c linux-2.6.5.scsi-replun/drivers/scsi/scsi_scan.c
@@ -80,7 +80,6 @@ module_param_named(max_luns, max_scsi_lu
 MODULE_PARM_DESC(max_luns,
 		 "last scsi LUN (should be between 1 and 2^32-1)");
 
-#ifdef CONFIG_SCSI_REPORT_LUNS
 /*
  * max_scsi_report_luns: the maximum number of LUNS that will be
  * returned from the REPORT LUNS command. 8 times this value must

@@ -88,13 +87,12 @@ MODULE_PARM_DESC(max_luns,
  * in practice, the maximum number of LUNs suppored by any device
  * is about 16k.
  */
-static unsigned int max_scsi_report_luns = 128;
+static unsigned int max_scsi_report_luns = 511;
 
 module_param_named(max_report_luns, max_scsi_report_luns, int, S_IRUGO|S_IWUSR);
 MODULE_PARM_DESC(max_report_luns,
 		 "REPORT LUNS maximum number of LUNS received (should be"
 		 " between 1 and 16384)");
-#endif
 
 /**
  * scsi_unlock_floptical - unlock device via a special MODE SENSE command

@@ -863,7 +861,6 @@ static void scsi_sequential_lun_scan(str
 			return;
 }
 
-#ifdef CONFIG_SCSI_REPORT_LUNS
 /**
  * scsilun_to_int: convert a scsi_lun to an int
  * @scsilun:	struct scsi_lun to be converted.

@@ -924,9 +921,14 @@ static int scsi_report_lun_scan(struct s
 	u8 *data;
 
 	/*
-	 * Only support SCSI-3 and up devices.
-	 */
-	if (sdev->scsi_level < SCSI_3)
+	 * Only support SCSI-3 and up devices if BLIST_NOREPORTLUN is not set.
+	 * Also allow SCSI-2 if BLIST_REPORTLUN2 is set and host adapter does
+	 * support more than 8 LUNs.
+	 */
+	if ((bflags & BLIST_NOREPORTLUN) || 
+	     sdev->scsi_level < SCSI_2 ||
+	    (sdev->scsi_level < SCSI_3 && 
+	     (!(bflags & BLIST_REPORTLUN2) || sdev->host->max_lun <= 8)) )
 		return 1;
 	if (bflags & BLIST_NOLUN)
 		return 0;

@@ -1090,9 +1092,6 @@ static int scsi_report_lun_scan(struct s
 	printk(ALLOC_FAILURE_MSG, __FUNCTION__);
 	return 0;
 }
-#else
-# define scsi_report_lun_scan(sdev, blags, rescan)	(1)
-#endif	/* CONFIG_SCSI_REPORT_LUNS */
 
 struct scsi_device *scsi_add_device(struct Scsi_Host *shost,
 				    uint channel, uint id, uint lun)

diff -uNrp linux-2.6.5/include/scsi/scsi_devinfo.h linux-2.6.5.scsi-replun/include/scsi/scsi_devinfo.h
@@ -21,4 +21,7 @@
 #define BLIST_MS_SKIP_PAGE_3F	0x4000	/* do not send ms page 0x3f */
 #define BLIST_USE_10_BYTE_MS	0x8000	/* use 10 byte ms before 6 byte ms */
 #define BLIST_MS_192_BYTES_FOR_3F	0x10000	/*  192 byte ms page 0x3f request */
+#define BLIST_REPORTLUN2	0x20000	/* try REPORT_LUNS even for SCSI-2 devs
+ 					   (if HBA supports more than 8 LUNs) */
+#define BLIST_NOREPORTLUN	0x40000	/* don't try REPORT_LUNS scan (SCSI-3 devs) */
 #endif

[email protected]

Feature

Make the timeout for INQUIRY during SCSI scan adjustable via boot parameter. Note that the second INQUIRY does use a shorter timeout, as the long timeout is for recovery from the initial reset, not because existing devices would take so long to answer INQUIRY. SPC3 says that INQUIRY should be available right away, but real life is different unfortunately.

diff -uNrp linux-2.6.5.dontattachoffl/drivers/scsi/scsi_scan.c linux-2.6.5.inq_timeout/drivers/scsi/scsi_scan.c
@@ -94,6 +94,13 @@ MODULE_PARM_DESC(max_report_luns,
 		 "REPORT LUNS maximum number of LUNS received (should be"
 		 " between 1 and 16384)");
 
+static unsigned int scsi_inq_timeout = SCSI_TIMEOUT/HZ+3;
+
+module_param_named(inq_timeout, scsi_inq_timeout, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(inq_timeout, 
+		 "Timeout (in seconds) waiting for devices to answer INQUIRY."
+		 " Default is 5. Some non-compliant devices need more.");
+
 /**
  * scsi_unlock_floptical - unlock device via a special MODE SENSE command
  * @sreq:	used to send the command

@@ -344,7 +351,7 @@ static void scsi_probe_lun(struct scsi_r
 
 	memset(inq_result, 0, 36);
 	scsi_wait_req(sreq, (void *) scsi_cmd, (void *) inq_result, 36,
-		      SCSI_TIMEOUT + 4 * HZ, 3);
+		      HZ/2 + HZ*scsi_inq_timeout, 3);
 
 	SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO "scsi scan: 1st INQUIRY %s with"
 			" code 0x%x\n", sreq->sr_result ?

@@ -393,7 +400,7 @@ static void scsi_probe_lun(struct scsi_r
 		memset(inq_result, 0, possible_inq_resp_len);
 		scsi_wait_req(sreq, (void *) scsi_cmd,
 			      (void *) inq_result,
-			      possible_inq_resp_len, SCSI_TIMEOUT + 4 * HZ, 3);
+			      possible_inq_resp_len, (1+scsi_inq_timeout)*(HZ/2), 3);
 		SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO "scsi scan: 2nd INQUIRY"
 				" %s with code 0x%x\n", sreq->sr_result ?
 				"failed" : "successful", sreq->sr_result));

Hi

(Removed Linus and Andrew from CC: not to bother them with such a "minor" issue:-))

I hoped the tmscsim 64-bit bugfix would somehow find its way into the mainstream after 2.6. Does it still have a chance?

Thanks
Guennadi
---
Guennadi Liakhovetski

The DC390 is a maintained driver:

DC390/AM53C974 SCSI driver
P: Kurt Garloff
M: [email protected]
W: http://www.garloff.de/kurt/linux/dc390/
S: Maintained

You need to get the maintainer to approve acceptance.

James

Well, I've pinged Kurt as few times on the driver, as did Guennadi. He never responded although he's quite active on linux-scsi on other issues..

...and it is very upsetting. Kurt helped me a lot during the initial porting of the driver to 2.6 and I very appreciate his help. I understand he is very and very busy and that driver is not top priority / importance, but still, I think, it wouldn't hurt anybody if it was reasonably supported / maintained. I think I did nothing wrong by proposing a patch, and it is just pity if it remains unused. It might (in principle) be wrong, and then I would appreciate at least a short explanation.

Thanks
Guennadi
---
Guennadi Liakhovetski