probing LUN's

[Tony Maher]

Hello Ken,

> > 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.

Ok.

> 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.

Yes it would.  However I think this problem could occur for other people
and 'fixing' it now (if possible while being consistent with standard)
would be nice.

> > 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.

Yes.

> 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.

I am happy to test out your patch, though I wont be able to test till
monday.

(BTW its running 5.1 release but I intend to test wih 4.8 as well
since in production it will be a 4.8R system)

thanks
--
tonym