probing LUN's

[Kenneth D. Merry]

On Thu, Jul 24, 2003 at 21:01:27 +1000, Tony Maher wrote:
> Hello,
> 
> > On Thu Jul 24 04:09:59 2003 "Kenneth D. Merry" wrote:
> > On Wed, Jul 23, 2003 at 10:35:34 -0700, Nate Lawson wrote:
> >> On Wed, 23 Jul 2003, Andrew Heybey wrote:
> >>>On Wed, 23 Jul 2003 21:25:44 +1000 (EST), Tony Maher said:
> 
> >>>   tonymaher> I assume this means that CAM does not probe all LUN's if
> >>>   tonymaher> no device at LUN 0 or sys/cam/cam_xpt.c has quirk entry
> >>>   tonymaher> for device that disables LUN probing.  There is quirk for
> >>>   tonymaher> {"HITACHI", "DK31*"} but the SAN reports as Hitachi
> >>>   tonymaher> DF600F (I think, sorry its at work and I cannot access it
> >>>   tonymaher> currently) so the second case shouldn't be a problem.
> >>>
> >>> You need the ispfw driver (either compiled-in or modloaded) to probe
> >>> luns beyond LUN 0 for the QLogic FC card.  If that is not your
> >>> problem, then I do not know...
> >> 
> >> That's true.  However, if camcontrol rescan 1:0:4 works for him, then he
> >> can try setting CAM_QUIRK_HILUNS for his device to get other luns probed
> >> when 0 doesn't respond.
> >
> > Actually, I don't know that that will cause the device on LUN 4 to show up
> > if LUN 0 isn't probing.  According to SAM-3, all SCSI devices must accept
> > LUN 0 as a valid address.
> >
> > Of course if it does respond on LUN 0, but just says that the LUN isn't
> > connected, we may still end up failing to probe additional LUNs..  It has
> > been a while since I looked at the probe code.
> >
> > It's worth a try, though.  I'm curious to hear whether that does the trick
> > or not.
> 
> Attempts to use CAM_QUIRK_HILUNS were not successful.
> Following Matt Jacobs pointer to the code I modified cam_xpt.c
> 
> *** Warning - cut'n'paste ***
> 
> --- cam_xpt.c   Thu Jul 24 01:58:46 2003
> +++ cam_xpt.c.orig      Wed Jul 23 23:23:02 2003
> @@ -5247,14 +5247,10 @@
>                                         device = TAILQ_NEXT(device, links);
>                         }
>                         splx(s);
> -                       if (lun_id < (CAM_SCSI2_MAXLUN-1) || phl)
> -                                       lun_id++;
> -/*
>                         if ((lun_id != 0) || (device != NULL)) {
>                                 if (lun_id < (CAM_SCSI2_MAXLUN-1) || phl)
>                                         lun_id++;
>                         }
> -*/
>                 } else {
>                         struct cam_ed *device;
> 
> And now it finds the HITACHI disk at boot.
> 
> I am not sure what you mean by "LUN 4 to show up > if LUN 0 isn't probing".
> There is no device at LUN 0 so the probe will return no device. The existing
> code gives up further probing at this point (no device at lun 0).
> This would appear to be a bug.

It may or may not be a bug.  As I said above, SAM-3 says that the device
must respond on LUN 0.

We don't know whether or not the device is responding on LUN 0.  It could
be responding to an INQUIRY, but just with a peripheral qualifier that is
non-zero.

If it is responding with a peripheral qualifier of 1, then it may well be
worth probing the LUNs to see what LUNs are supported, or perhaps issuing a
REPORT LUNS command to see what it claims to support.

If it is responding with a peripheral qualifier of 3, then it isn't being
truthful, because it can support a LUN at that address.

If it isn't responding to an INQUIRY at that LUN at all, then it isn't
following the spec.

> Some background on the SAN setup.
> There are two controllers, one direct connect to Sun box
>                            one direct connect to FreeBSD box
> There are two 'logical' raid 5 sets, one assigned to each controller.
> On the Sun it sees LUNS 0-3, and FreeBSD sees LUN 4.
> It would appear that there is just on physical raid 5 but it is subdivided.
> I also learnt today from my colleague that you can map LUN 4 to LUN 0
> on the second controller (at least to the host freebsd box it will be at LUN
> 0).

Sounds like changing the configuration might be an easy way to make things
work properly.

> However given likelyhood of more SAN devices in future (with 'strange'
> configurations) it would be nice if FreeBSD probed all LUNs.
> It isn't a big cost is it?
> If it is could we have a kernel option CAM_PROBE_ALL_LUNS?

We may be able to solve it generically...it really depends on what the
device is doing.  There isn't a quick way to figure that out from userland,
it'll take a kernel patch with a few printfs to figure out whether it is
returning any inquiry data for LUN 0, and then what the peripheral
qualifier is.

If you're willing to try it out, I can probably come up with a patch
tomorrow.  That would at least tell us what would need to be done to make
it probe.

Ken
-- 
Kenneth Merry
ken at kdm.org