linux-2.4.12-scsi_scan.patch

   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 @@ -795,11 +827,26 @@
  28                  * I think we need REPORT LUNS in future to avoid scanning
  29                  * of unused LUNs. But, that is another item.
  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 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
  49 +                */
  50 +               *max_dev_lun = shpnt->max_lun;
  51                 return 1;
  52         }
  53         /*