[BK PATCH] SCSI updates for 2.6.6

[BK PATCH] SCSI updates for 2.6.6

[James Bottomley]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BK PATCH] SCSI updates for 2.6.6

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Hi James,

On Mon, May 10, 2004 at 05:59:31PM -0500, James Bottomley wrote:
> This is the latest set of assorted fixes, plus one new driver: the IBM
> Power Raid (ipr).
> Kurt Garloff:
>   o scsi: don't attach device if PQ indicates not connected

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

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK PATCH] SCSI updates for 2.6.6

[James Bottomley]

On Tue, 2004-05-11 at 07:34, Kurt Garloff wrote:
> Should I resubmit the other SCSI scanning/blacklist patches or are they
> queued? Or rejected?

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

James

Re: [BK PATCH] SCSI updates for 2.6.6

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]

Hi James,

sorry for the late response.

On Tue, May 11, 2004 at 08:42:41AM -0500, James Bottomley wrote:
> On Tue, 2004-05-11 at 07:34, Kurt Garloff wrote:
> > Should I resubmit the other SCSI scanning/blacklist patches or are they
> > queued? Or rejected?
> 
> I thought' I'd put in all the necessary ones, what's missing?

(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  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                        Director SUSE Labs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK PATCH] SCSI updates for 2.6.6

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]

On Mon, May 17, 2004 at 09:52:42PM +0200, Kurt Garloff wrote:
> If wanted, I can rediff and resubmit.

Patches against 2.6.6 attached.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                        Director SUSE Labs

[-- Attachment #1.2: scsi-log-unlikely.diff --]
[-- Type: text/plain, Size: 553 bytes --]

garloff@suse.de

Optimization.

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

--- linux-2.6.5/drivers/scsi/scsi_logging.h.orig	2004-04-04 05:36:17.000000000 +0200
+++ linux-2.6.5/drivers/scsi/scsi_logging.h	2004-04-15 21:18:42.284491405 +0200
@@ -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

[-- Attachment #1.3: scsi-scan-deprecate-forcelun.diff --]
[-- Type: text/plain, Size: 1840 bytes --]

garloff@suse.de

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
--- linux-2.6.5.scsi-orig/drivers/scsi/Kconfig	2004-04-21 14:17:50.000000000 +0200
+++ linux-2.6.5.depr-forcelun/drivers/scsi/Kconfig	2004-04-21 14:23:23.000000000 +0200
@@ -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
--- linux-2.6.5.scsi-orig/include/scsi/scsi_devinfo.h	2004-04-04 05:36:14.000000000 +0200
+++ linux-2.6.5.depr-forcelun/include/scsi/scsi_devinfo.h	2004-04-21 14:24:40.000000000 +0200
@@ -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 */

[-- Attachment #1.4: scsi-scan-blist-replun.diff --]
[-- Type: text/plain, Size: 4631 bytes --]

garloff@suse.de

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
--- linux-2.6.5/drivers/scsi/Kconfig	2004-05-19 00:44:04.000000000 +0200
+++ linux-2.6.5.scsi-replun/drivers/scsi/Kconfig	2004-05-19 00:52:04.000000000 +0200
@@ -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
--- linux-2.6.5/drivers/scsi/scsi_scan.c	2004-05-19 00:44:04.000000000 +0200
+++ linux-2.6.5.scsi-replun/drivers/scsi/scsi_scan.c	2004-05-19 00:52:04.000000000 +0200
@@ -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
--- linux-2.6.5/include/scsi/scsi_devinfo.h	2004-05-19 00:44:04.000000000 +0200
+++ linux-2.6.5.scsi-replun/include/scsi/scsi_devinfo.h	2004-05-19 00:53:01.000000000 +0200
@@ -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

[-- Attachment #1.5: scsi-scan-inq-timeout.diff --]
[-- Type: text/plain, Size: 2100 bytes --]

garloff@suse.de

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
--- linux-2.6.5.dontattachoffl/drivers/scsi/scsi_scan.c	2004-04-21 14:28:13.000000000 +0200
+++ linux-2.6.5.inq_timeout/drivers/scsi/scsi_scan.c	2004-04-21 14:32:04.000000000 +0200
@@ -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));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BK PATCH] SCSI updates for 2.6.6

[Guennadi Liakhovetski]

Hi

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

On 10 May 2004, James Bottomley wrote:

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

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

Re: [BK PATCH] SCSI updates for 2.6.6

[James Bottomley]

On Tue, 2004-05-11 at 14:29, Guennadi Liakhovetski wrote:
> I hoped the tmscsim 64-bit bugfix would somehow find its way into the
> mainstream after 2.6. Does it still have a chance?

The DC390 is a maintained driver:

DC390/AM53C974 SCSI driver
P:	Kurt Garloff
M:	garloff@suse.de
W:	http://www.garloff.de/kurt/linux/dc390/
S:	Maintained

You need to get the maintainer to approve acceptance.

James

Re: [BK PATCH] SCSI updates for 2.6.6

[Christoph Hellwig]

On Tue, May 11, 2004 at 02:54:33PM -0500, James Bottomley wrote:
> On Tue, 2004-05-11 at 14:29, Guennadi Liakhovetski wrote:
> > I hoped the tmscsim 64-bit bugfix would somehow find its way into the
> > mainstream after 2.6. Does it still have a chance?
> 
> The DC390 is a maintained driver:

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..

Re: [BK PATCH] SCSI updates for 2.6.6

[Guennadi Liakhovetski]

On Tue, 11 May 2004, Christoph Hellwig wrote:

> On Tue, May 11, 2004 at 02:54:33PM -0500, James Bottomley wrote:
> > On Tue, 2004-05-11 at 14:29, Guennadi Liakhovetski wrote:
> > > I hoped the tmscsim 64-bit bugfix would somehow find its way into the
> > > mainstream after 2.6. Does it still have a chance?
> >
> > The DC390 is a maintained driver:
>
> 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

Re: [BK PATCH] SCSI updates for 2.6.6

[Guennadi Liakhovetski]

On Tue, 18 May 2004, Kurt Garloff wrote:

> On Tue, May 11, 2004 at 02:54:33PM -0500, James Bottomley wrote:
> > On Tue, 2004-05-11 at 14:29, Guennadi Liakhovetski wrote:
> > > I hoped the tmscsim 64-bit bugfix would somehow find its way into the
> > > mainstream after 2.6. Does it still have a chance?
> >
> > The DC390 is a maintained driver:
> >
> > DC390/AM53C974 SCSI driver
> > P:	Kurt Garloff
> > M:	garloff@suse.de
> > W:	http://www.garloff.de/kurt/linux/dc390/
> > S:	Maintained
> >
> > You need to get the maintainer to approve acceptance.
>
> Granted ;-)
>
> Actually, I had discussed the patch before with Guennadi and agreed to
> it. As I don't really have much time any more for it, I would suggest
> that Guennadi takes over, if he wants to.

Well, Kurt, thanks for the offer. I am prepared and willing to do the work
on supporting the driver, but I am, perhaps, not skilled enough to be a
maintainer of a SCSI LDD. My knowledge of the SCSI protocol and the SCSI
Linux subsystem is pretty limited. On one hand, the driver is little used,
so, even if I badly break something it is not likely to cause major
problems. On the other hand, I would feel more comfortable if, at least at
the beginning, somebody would review my patches. Besides, it would be a
good opportunity for me to really learn a bit more about SCSI, SCSI Linux
driver, BIO,...  oh well...

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [BK PATCH] SCSI updates for 2.6.6

[James Bottomley]

On Tue, 2004-05-18 at 14:47, Guennadi Liakhovetski wrote:
> Well, Kurt, thanks for the offer. I am prepared and willing to do the work
> on supporting the driver, but I am, perhaps, not skilled enough to be a
> maintainer of a SCSI LDD. My knowledge of the SCSI protocol and the SCSI
> Linux subsystem is pretty limited. On one hand, the driver is little used,
> so, even if I badly break something it is not likely to cause major
> problems. On the other hand, I would feel more comfortable if, at least at
> the beginning, somebody would review my patches. Besides, it would be a
> good opportunity for me to really learn a bit more about SCSI, SCSI Linux
> driver, BIO,...  oh well...

OK, roll up for me what you'd currently like applied to the driver;
anything that's less than solid, I'd rather mature in the -mm tree for a
while.

James

Re: [BK PATCH] SCSI updates for 2.6.6

[Chiaki]

Well this may be a little off topic.

But I would like to thank Kurt for supporting DC390 back in 1997 (or 
1996? I know it was before the France World Cup soccer games)
when I was contemplating of moving to Solaris or linux from OS/2.

Without his support to fix some problems (module usage, etc.),
I would not have moved to linux at all.

The DC390 is still working in my PC box to connect HP DAT2 tape drive
and CD/PD combo while faster SCSI disks are connected on other
boards.

Thank you again, Garloff-san !

PS: This trusty AMD chip board may be still alive in many
PC boxes around the world...

James Bottomley wrote:
> On Tue, 2004-05-18 at 14:47, Guennadi Liakhovetski wrote:
> 
>>Well, Kurt, thanks for the offer. I am prepared and willing to do the work
>>on supporting the driver, but I am, perhaps, not skilled enough to be a
>>maintainer of a SCSI LDD. My knowledge of the SCSI protocol and the SCSI
>>Linux subsystem is pretty limited. On one hand, the driver is little used,
>>so, even if I badly break something it is not likely to cause major
>>problems. On the other hand, I would feel more comfortable if, at least at
>>the beginning, somebody would review my patches. Besides, it would be a
>>good opportunity for me to really learn a bit more about SCSI, SCSI Linux
>>driver, BIO,...  oh well...
> 
> 
> OK, roll up for me what you'd currently like applied to the driver;
> anything that's less than solid, I'd rather mature in the -mm tree for a
> while.
> 
> James
> 
>


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: [BK PATCH] SCSI updates for 2.6.6

[Matthew Wilcox]

On Tue, May 18, 2004 at 09:47:56PM +0200, Guennadi Liakhovetski wrote:
> Well, Kurt, thanks for the offer. I am prepared and willing to do the work
> on supporting the driver, but I am, perhaps, not skilled enough to be a
> maintainer of a SCSI LDD. My knowledge of the SCSI protocol and the SCSI
> Linux subsystem is pretty limited. On one hand, the driver is little used,
> so, even if I badly break something it is not likely to cause major
> problems. On the other hand, I would feel more comfortable if, at least at
> the beginning, somebody would review my patches. Besides, it would be a
> good opportunity for me to really learn a bit more about SCSI, SCSI Linux
> driver, BIO,...  oh well...

Don't worry about it.  You'll learn these things in time ...
If Kurt's willing to review your patches when you send them,
that'd be best (but don't necessarily wait for Kurt's ack before applying).

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain