probing LUN's

[Tony Maher]

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.

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

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?

thanks for your time
--
tonym