blacklist device don't use SYNCHRONIZE_CACHE

PATCH In review Michael Clark 1 participant 2 messages Oct 29, 2004 SCSI

lore

Share & tools

lore

Michael Clark

author

2004-10-29 09:00 UTC #0 lore raw

PATCH 1/1 blacklist device don't use SYNCHRONIZE_CACHE

Hi all,

With qla2300 loaded (and sdc a LUN on an external FC RAID controller), I was getting a hang on reboot at:

Synchronizing SCSI cache for disk sdc:

I did some debugging by changing the timeout in sd_sync_cache and found the RAID Controller was just dropping the commands (it's an external battery backed RAID array so the sd_sync_cache is not important anyway).

So, attached patch adds to the SCSI blacklist infrastructure to allow listing devices for which we shouldn't send a SYNCRONIZE_CACHE command and adds in the misbehaving device i have here.

Now I can reboot ;) without waiting 7.5 minutes.

BTW - The default of 15 retries of 30 secs each is insane (3 in sd_sync_cache x 5 in scsi_wait_req) - any real need for the additional outer loop in sd_sync_cache ?

~mc

Adds a flag to the SCSI blacklist infrastructure to allow marking devices we shouldn't send a SYNCRONIZE_CACHE command to. Adds the Chaparral JFS224 to the blacklist with this flag.

Signed-off-by Michael Clark <[email protected]>

drivers/scsi/scsi_devinfo.c +1 -0

diff -ur linux-2.6.9.orig/drivers/scsi/scsi_devinfo.c linux-2.6.9.edited/drivers/scsi/scsi_devinfo.c
@@ -125,6 +125,7 @@
 	{"CMD", "CRA-7280", NULL, BLIST_SPARSELUN},	/* CMD RAID Controller */
 	{"CNSI", "G7324", NULL, BLIST_SPARSELUN},	/* Chaparral G7324 RAID */
 	{"CNSi", "G8324", NULL, BLIST_SPARSELUN},	/* Chaparral G8324 RAID */
+	{"CNSi", "JFS224", NULL, BLIST_SPARSELUN | BLIST_NO_SYNC_CACHE},
 	{"COMPAQ", "LOGICAL VOLUME", NULL, BLIST_FORCELUN},
 	{"COMPAQ", "CR3500", NULL, BLIST_FORCELUN},
 	{"COMPAQ", "MSA1000", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},

drivers/scsi/scsi_scan.c +3 -0

diff -ur linux-2.6.9.orig/drivers/scsi/scsi_scan.c linux-2.6.9.edited/drivers/scsi/scsi_scan.c
@@ -668,6 +668,9 @@
 	if (*bflags & BLIST_NOT_LOCKABLE)
 		sdev->lockable = 0;
 
+	if (*bflags & BLIST_NO_SYNC_CACHE)
+		sdev->no_sync_cache = 1;
+
 	if(sdev->host->hostt->slave_configure)
 		sdev->host->hostt->slave_configure(sdev);

drivers/scsi/sd.c +3 -0

diff -ur linux-2.6.9.orig/drivers/scsi/sd.c linux-2.6.9.edited/drivers/scsi/sd.c
@@ -1560,6 +1560,9 @@
 	if (!sdkp->WCE)
 		return;
 
+	if(sdp->no_sync_cache)
+		return;
+
 	printk(KERN_NOTICE "Synchronizing SCSI cache for disk %s: \n",
 			sdkp->disk->disk_name);
 	sd_sync_cache(sdp);

include/scsi/scsi_device.h +1 -0

diff -ur linux-2.6.9.orig/include/scsi/scsi_device.h linux-2.6.9.edited/include/scsi/scsi_device.h
@@ -106,6 +106,7 @@
 	unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
 	unsigned no_start_on_add:1;	/* do not issue start on add */
 	unsigned allow_restart:1; /* issue START_UNIT in error handler */
+	unsigned no_sync_cache:1;	/* do not issue SYNCRONIZE_CACHE */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */

include/scsi/scsi_devinfo.h +1 -0

diff -ur linux-2.6.9.orig/include/scsi/scsi_devinfo.h linux-2.6.9.edited/include/scsi/scsi_devinfo.h
@@ -25,4 +25,5 @@
  					   (if HBA supports more than 8 LUNs) */
 #define BLIST_NOREPORTLUN	0x40000	/* don't try REPORT_LUNS scan (SCSI-3 devs) */
 #define BLIST_NOT_LOCKABLE	0x80000	/* don't use PREVENT-ALLOW commands */
+#define BLIST_NO_SYNC_CACHE	0x100000 /* don't use SYNCHRONIZE_CACHE commands */
 #endif

Michael Clark

author

2004-10-29 09:04 UTC #1 lore raw

Apologies for base64 attachment - if anyone can tell me how to stop my Debian Mozilla 1.7 from randomly deciding to base64 my attached patches (it only decides to do it on some of them).

~mc

Quoted 23 lines · Michael Clark

Hi all,
With qla2300 loaded (and sdc a LUN on an external FC RAID controller), I was getting a hang on reboot at:
Synchronizing SCSI cache for disk sdc:
I did some debugging by changing the timeout in sd_sync_cache and found the RAID Controller was just dropping the commands (it's an external battery backed RAID array so the sd_sync_cache is not important anyway).
So, attached patch adds to the SCSI blacklist infrastructure to allow listing devices for which we shouldn't send a SYNCRONIZE_CACHE command and adds in the misbehaving device i have here.
Now I can reboot ;) without waiting 7.5 minutes.
BTW - The default of 15 retries of 30 secs each is insane (3 in sd_sync_cache x 5 in scsi_wait_req) - any real need for the additional outer loop in sd_sync_cache ?
~mc