1 --- linux/drivers/scsi/scsi_scan.c.save Wed Mar 14 20:58:21 2001
2 +++ linux/drivers/scsi/scsi_scan.c Wed Mar 14 21:10:28 2001
7 + * If we are offline and we are on a LUN != 0, then skip this entry.
8 + * If we are on a BLIST_FORCELUN device this will stop the scan at
9 + * the first offline LUN (typically the correct thing to do). If
10 + * we are on a BLIST_SPARSELUN device then this won't stop the scan,
11 + * but it will keep us from having false entries in our device
14 + * NOTE: Need to test this to make sure it doesn't cause problems
15 + * with tape autoloaders, multidisc CD changers, and external
16 + * RAID chassis that might use sparse luns or multiluns... DL
18 + if (lun != 0 && (scsi_result[0] >> 5) == 1) {
19 + scsi_release_request(SRpnt);
24 * Get any flags for this device.
26 bflags = get_device_flags (scsi_result);
28 * I think we need REPORT LUNS in future to avoid scanning
29 * of unused LUNs. But, that is another item.
32 if (*max_dev_lun < shpnt->max_lun)
33 *max_dev_lun = shpnt->max_lun;
34 else if ((max_scsi_luns >> 1) >= *max_dev_lun)
35 *max_dev_lun += shpnt->max_lun;
36 else *max_dev_lun = max_scsi_luns;
39 + * Blech...the above code is broken. When you have a device
40 + * that is present, and it is a FORCELUN device, then we
41 + * need to scan *all* the luns on that device. Besides,
42 + * skipping the scanning of LUNs is a false optimization.
43 + * Scanning for a LUN on a present device is a very fast
44 + * operation, it's scanning for devices that don't exist that
45 + * is expensive and slow (although if you are truly scanning
46 + * through MAX_SCSI_LUNS devices that would be bad, I hope
47 + * all of the controllers out there set a reasonable value
48 + * in shpnt->max_lun). DL
50 + *max_dev_lun = shpnt->max_lun;