projects / packages / kernel.git / blame
| Commit | Line | Data |
|---|---|---|
| 95e83f51 JR |
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 | |
| 3 | @@ -557,6 +557,23 @@ | |
| 4 | } | |
| 5 | ||
| 6 | /* | |
| 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 | |
| 12 | + * array. DL | |
| 13 | + * | |
| 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 | |
| 17 | + */ | |
| 18 | + if (lun != 0 && (scsi_result[0] >> 5) == 1) { | |
| 19 | + scsi_release_request(SRpnt); | |
| 20 | + return 0; | |
| 21 | + } | |
| 22 | + | |
| 23 | + /* | |
| 24 | * Get any flags for this device. | |
| 25 | */ | |
| 26 | bflags = get_device_flags (scsi_result); | |
| 27 | @@ -776,11 +793,26 @@ | |
| 28 | * | |
| 29 | * FIXME(eric) - perhaps this should be a kernel configurable? | |
| 30 | */ | |
| 31 | + /* | |
| 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; | |
| 37 | + */ | |
| 38 | + /* | |
| 39 | + * Blech...the above code is broken. When you have a device | |
| 40 | + * that is present, and it is a SPARSELUN 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 | |
| 49 | + */ | |
| 50 | + *max_dev_lun = shpnt->max_lun; | |
| 51 | *sparse_lun = 1; | |
| 52 | return 1; | |
| 53 | } | |
| 54 | @@ -795,11 +827,26 @@ | |
| 55 | * I think we need REPORT LUNS in future to avoid scanning | |
| 56 | * of unused LUNs. But, that is another item. | |
| 57 | */ | |
| 58 | + /* | |
| 59 | if (*max_dev_lun < shpnt->max_lun) | |
| 60 | *max_dev_lun = shpnt->max_lun; | |
| 61 | else if ((max_scsi_luns >> 1) >= *max_dev_lun) | |
| 62 | *max_dev_lun += shpnt->max_lun; | |
| 63 | else *max_dev_lun = max_scsi_luns; | |
| 64 | + */ | |
| 65 | + /* | |
| 66 | + * Blech...the above code is broken. When you have a device | |
| 67 | + * that is present, and it is a FORCELUN device, then we | |
| 68 | + * need to scan *all* the luns on that device. Besides, | |
| 69 | + * skipping the scanning of LUNs is a false optimization. | |
| 70 | + * Scanning for a LUN on a present device is a very fast | |
| 71 | + * operation, it's scanning for devices that don't exist that | |
| 72 | + * is expensive and slow (although if you are truly scanning | |
| 73 | + * through MAX_SCSI_LUNS devices that would be bad, I hope | |
| 74 | + * all of the controllers out there set a reasonable value | |
| 75 | + * in shpnt->max_lun). DL | |
| 76 | + */ | |
| 77 | + *max_dev_lun = shpnt->max_lun; | |
| 78 | return 1; | |
| 79 | } | |
| 80 | /* |