probing LUN's

[Kenneth D. Merry]

On Fri, Jul 25, 2003 at 18:46:25 +1000, Tony Maher wrote:
> 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.

I agree.

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

I have attached a patch.  I think it'll work on 5.1.  It's pretty simple in
any case, so it should be pretty easy to put it in.

Just apply the patch, rebuild your kernel and reinstall (use a different
kernel name than the default, since you won't want this by default).

Then send the full dmesg output.

That should give us an idea of what the device is returning.

Ken
-- 
Kenneth Merry
ken at kdm.org
-------------- next part --------------
==== //depot/FreeBSD-ken/src/sys/cam/cam_xpt.c#40 - /usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/cam_xpt.c ====
*** /tmp/tmp.282.0	Fri Jul 25 22:57:04 2003
--- /usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/cam_xpt.c	Fri Jul 25 22:28:50 2003
***************
*** 5789,5794 ****
--- 5789,5802 ----
  				xpt_schedule(periph, priority);
  				return;
  			}
+ 			case SID_QUAL_LU_OFFLINE:
+ 				xpt_print_path(path);
+ 				printf("LUN offline\n");
+ 				break;
+ 			case SID_QUAL_BAD_LU:
+ 				xpt_print_path(path);
+ 				printf("LUN offline\n");
+ 				break;
  			default:
  				break;
  			}