public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* scsi_scan problem.
@ 2001-03-15  2:28 Doug Ledford
  2001-03-15  2:35 ` Pete Zaitcev
  2001-03-16 22:39 ` Rafael E. Herrera
  0 siblings, 2 replies; 16+ messages in thread
From: Doug Ledford @ 2001-03-15  2:28 UTC (permalink / raw)
  To: linux-kernel, linux-scsi

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


A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
sees multiple identical luns in different scenarios) was not a bug in the
qla2x00 driver.  The recent changes to allow max luns in the mid layer to be >
7 seems to have caused this problem.  However, the proper fix is a bit of a
quandry for me.  You see, I don't have any Nakamichi or Yamaha multi-cd
changers, or a DAT or DLT autoloader, or several of the different models of
raid chassis.  The bug is that we were detecting offline devices and linking
them into the device list.  But, some devices (at least the Clariion raid
chassis) report luns that don't currently have any device bound to them as
present but offline.  This meant if we truly scanned all luns then we got
something like 100+ devices on one ID from this chassis when only 1 might be
valid :-(  So, I've attached a patch that solves the problem here perfectly. 
But, I need people that have access to the above listed hardware to test it. 
Most specifically, I'm afraid that the CD changers or autoloaders will report
some of their luns as offline so we will skip them even though we want them
entered into the device list.  If that's not the case, and they list their
luns as all being connected, then this patch needs to go into the mainstream
kernel.

-- 

 Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
      Please check my web site for aic7xxx updates/answers before
                      e-mailing me about problems

[-- Attachment #2: scsi_scan.patch --]
[-- Type: text/plain, Size: 2871 bytes --]

--- scsi_scan.c.save	Wed Mar 14 20:58:21 2001
+++ scsi_scan.c	Wed Mar 14 21:10:28 2001
@@ -557,6 +557,23 @@
 	}
 
 	/*
+	 * If we are offline and we are on a LUN != 0, then skip this entry.
+	 * If we are on a BLIST_FORCELUN device this will stop the scan at
+	 * the first offline LUN (typically the correct thing to do).  If
+	 * we are on a BLIST_SPARSELUN device then this won't stop the scan,
+	 * but it will keep us from having false entries in our device
+	 * array. DL
+	 *
+	 * NOTE: Need to test this to make sure it doesn't cause problems
+	 * with tape autoloaders, multidisc CD changers, and external
+	 * RAID chassis that might use sparse luns or multiluns... DL
+	 */
+	if (lun != 0 && (scsi_result[0] >> 5) == 1) {
+		scsi_release_request(SRpnt);
+		return 0;
+	}
+
+	/*
 	 * Get any flags for this device.  
 	 */
 	bflags = get_device_flags (scsi_result);
@@ -776,11 +793,26 @@
 		 *
 		 * FIXME(eric) - perhaps this should be a kernel configurable?
 		 */
+		/*
 		if (*max_dev_lun < shpnt->max_lun)
 			*max_dev_lun = shpnt->max_lun;
 		else 	if ((max_scsi_luns >> 1) >= *max_dev_lun)
 				*max_dev_lun += shpnt->max_lun;
 			else	*max_dev_lun = max_scsi_luns;
+		*/
+		/*
+		 * Blech...the above code is broken.  When you have a device
+		 * that is present, and it is a SPARSELUN device, then we
+		 * need to scan *all* the luns on that device.  Besides,
+		 * skipping the scanning of LUNs is a false optimization.
+		 * Scanning for a LUN on a present device is a very fast
+		 * operation, it's scanning for devices that don't exist that
+		 * is expensive and slow (although if you are truly scanning
+		 * through MAX_SCSI_LUNS devices that would be bad, I hope
+		 * all of the controllers out there set a reasonable value
+		 * in shpnt->max_lun).  DL
+		 */
+		*max_dev_lun = shpnt->max_lun;
 		*sparse_lun = 1;
 		return 1;
 	}
@@ -795,11 +827,26 @@
 		 * I think we need REPORT LUNS in future to avoid scanning
 		 * of unused LUNs. But, that is another item.
 		 */
+		/*
 		if (*max_dev_lun < shpnt->max_lun)
 			*max_dev_lun = shpnt->max_lun;
 		else 	if ((max_scsi_luns >> 1) >= *max_dev_lun)
 				*max_dev_lun += shpnt->max_lun;
 			else	*max_dev_lun = max_scsi_luns;
+		*/
+		/*
+		 * Blech...the above code is broken.  When you have a device
+		 * that is present, and it is a FORCELUN device, then we
+		 * need to scan *all* the luns on that device.  Besides,
+		 * skipping the scanning of LUNs is a false optimization.
+		 * Scanning for a LUN on a present device is a very fast
+		 * operation, it's scanning for devices that don't exist that
+		 * is expensive and slow (although if you are truly scanning
+		 * through MAX_SCSI_LUNS devices that would be bad, I hope
+		 * all of the controllers out there set a reasonable value
+		 * in shpnt->max_lun).  DL
+		 */
+		*max_dev_lun = shpnt->max_lun;
 		return 1;
 	}
 	/*

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-03-17  3:38 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-15  2:28 scsi_scan problem Doug Ledford
2001-03-15  2:35 ` Pete Zaitcev
2001-03-15  3:03   ` Doug Ledford
2001-03-15  3:09     ` Doug Ledford
2001-03-16 16:53     ` Ishikawa
2001-03-16 19:33       ` Doug Ledford
2001-03-16 20:10         ` Peter Rival
2001-03-17  2:08         ` Ishikawa
2001-03-15  5:06   ` Bob Frey
2001-03-15  5:19     ` Doug Ledford
2001-03-16 22:39 ` Rafael E. Herrera
2001-03-16 22:54   ` Doug Ledford
2001-03-16 23:40   ` Khalid Aziz
2001-03-17  0:12   ` Patrick Mansfield
2001-03-17  1:56     ` Doug Ledford
2001-03-17  3:37     ` Rafael E. Herrera

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox