> 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 011
On Tue, Jun 19, 2001 at 11:08:40AM -0700, Poul Petersen wrote:
> > This way, the device at LUN 0 is found to start the scan, and
> > then later
>
> On a more general question - in order to work around the
> Zzyzx problem, I have moved the call to get_device_flags
> as before and added (I
> This way, the device at LUN 0 is found to start the scan, and
> then later
On a more general question - in order to work around the
Zzyzx problem, I have moved the call to get_device_flags
as before and added (I also removed all traces of BLIST_FORCESCAN)
bflags = get_devic
> This has worked on all Dell PowerVault SANs. If the
> RocketStor 500S is
> returning 011b rather than 001b there, then I believe that's
> a bug in their
> SCSI implementation. Can you add a check to see what's
> actually in the
> peripheral qualifier field when there's no LUN available?
>
> I have a Dell 2300 running RedHat 7.1 with the 2.4.3
> kernel. We are
> using a qlogic QLA2200 FC card to connect to a Zzyzx
> RocketStor Raid array.
> The Zzyzx array has two FC ports which appear as two targets
> on the SAN and
> can assign raid sets to arbitrary Lun numbers on either
I have a Dell 2300 running RedHat 7.1 with the 2.4.3 kernel. We are
using a qlogic QLA2200 FC card to connect to a Zzyzx RocketStor Raid array.
The Zzyzx array has two FC ports which appear as two targets on the SAN and
can assign raid sets to arbitrary Lun numbers on either port. The prob
6 matches
Mail list logo
