1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
--- linux/drivers/scsi/scsi_scan.c.save Wed Mar 14 20:58:21 2001
+++ linux/drivers/scsi/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);
@@ -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;
}
/*
|
