Re: Apple Xserve RAID and qlogic ISP2312 (qla2300)

[Patrick Mansfield <patmans@us.ibm.com>]

On Fri, Oct 29, 2004 at 11:58:00AM +0300, Catalin Muresan wrote:

>  > > Catalin - does the device support REPORT LUNS? Do you have that
>  > > configured? It would avoid this problem.
>  > > 
>  > 
>  > Yes, Catalin, could you find that out?  I've only had a small amount
>  > of exposure with the XRAID box and know that there were some quirks
>  > about the device not performing an RFT_ID with the SNS, not sure if
>  > that was addressed.
> 
> 	i don't know how to find that, i'm gonna go and look at the source
> and try to figure it out untill you respond.

I forgot a few things:

1) The REPORT LUNS is always on in current 2.6.x kernels, I do not remember
what kernel version first had the change.

2) If LUN 0 gets a DID_NO_CONNECT (and we do return the
SCSI_SCAN_NO_RESPONSE), we won't scan anything, via REPORT LUN or via
a sequential scan.

3) We have a problem for REPORT LUN with sparse lun devices, in short,
you won't get a REPORT LUN scan if no LUN 0 is configured. I thought Kurt
was working on a fix for that, this post:

http://marc.theaimsgroup.com/?t=109545967900002&r=1&w=2

4) You posted as part of your logs:

Oct 28 02:31:38 zerg-b kernel:   Vendor: APPLE     Model: Xserve RAID Rev: 1.21
Oct 28 02:31:38 zerg-b kernel:   Type:   Direct-Access ANSI SCSI revision: 02

For SCSI 2 devices by default the REPORT LUN scan won't be used. Some
storage arrays have an option as to what SCSI level to report, try that or
use the BLIST_REPORTLUN2 devinfo flag. 

If you had configured in only LUNs 0 1 and 5, the sequential scan (with no
sparse lun) will stop scanning after LUN 2 is not seen.

In short you need to first figure out why LUN 0 is getting a
DID_NO_CONNECT, and after that the sequential scan should work OK for your
*current* configuration (only LUN 5 configured), though the REPORT LUN
scan or sparse lun scan will be needed to avoid sparse LUNs as noted
above.

-- Patrick Mansfield