> The above is a good idea, but the get/check of the flags should
> happen after the sr_result.
Good point.
> A peripheral qualifier (PQ) of 011b should not halt the scan
> for a sparse
> LUN device - current behaviour without your change above is
> to halt all
> scans if LUN 0 has 011b, but for sparse LUN devices, if LUN 0
> is "found",
> other LUNs with 011b would not halt the scan.
...
> For linux, returning a 001b can be bad, as it will allocate a
> Scsi_Device,
> and use up an sd entry (and you can never access the device).
> Doug Ledford
> posted a patch to skip these (apparently it is included in the redhat
> 7.1 2.4.2-2 kernel).
Indeed - How do we sort this out then? As it stands, scsi_scan
halts even on a known sparse_lun device if LUN 0 returns 011b. This is
undesirable because a sparse LUN device need not have a device at LUN 0.
If instead the device returns 001b on LUN 0 even when there is no device
present at LUN 0, then the scan will work properly for the remaining LUNs
but we may get an invalid SCSI device at LUN 0.
It would seem that the call to get_device_flags and the setting of
*sparse_lun should occur before the peripheral qualifier test. Then it
would be irrelevant whether the sparse LUN device returned 001b or 011b
on LUN 0. In fact, returning 011b in this circumstance works perfectly and
returning 001b works just as before.
BTW, I've heard the IRIX has the same problem with Zzyzx - that is
it recognizes the sparse LUNs, but only if a device is present at LUN 0.
Certainly we don't want to be like SGI? :)
Thanks for your thoughts,
-poul
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]