AW: AW: only 8 LUNs on MPT
Scott Long
scottl at samsco.org
Sat Mar 8 15:57:52 UTC 2008
Kenneth D. Merry wrote:
> On Fri, Mar 07, 2008 at 08:55:36 -0700, Scott Long wrote:
>> d_elbracht wrote:
>>> the tunable is set:
>>> sysctl -a | grep kern.cam.cam_srch
>>> kern.cam.cam_srch_hi: 1
>>>
>>> here is the output from 'camcontrol inq da45':
>>>
>>> pass45: <IFT S16S-G1030 361F> Fixed Direct Access SCSI-4 device
>>> pass45: Serial Number 01F53A00000000472CF136000000
>>> 300.000MB/s transfers , Command Queueing Enabled
>>>
>>> Dieter
>>>
>> What version of FreeBSD is this? The max lun benhavior changed a
>> bit in the SCSI layer a couple of years ago. The MPT driver itself
>> supports up to 256 LUNs.
>
> I think the problem may be:
>
> cpi->max_lun = 7;
>
> That's from line 3590 in rev 1.63 of mpt_cam.c. (i.e. -current)
>
> I ran into the same problem a few days ago in RELENG_7, but hadn't gotten
> around to sending email about it yet.
>
> The symptom I was having is all the LUNs on the target wouldn't probe
> automatically. I could rescan them manually, but CAM would stop probing at
> 7.
>
> I fixed it by setting max_lun to 1024. (Not sure if anything would break
> if I actually got that high, but my target was only setup for 79 LUNs.)
>
> Ken
Ok, I missed it on my first look since there's code elsewhere in the
driver that specifically handles up to 16k LUNs as an initiator and 256
LUNs as a target. I guess the value in XPT_PATH_INQ is there so that
CAM won't spend hours at boot-time scanning for all possible LUNs. I
could change it to something like 256, but that will still significantly
increase the boot time. What really needs to happen is to have
REPORT_LUNS implemented for the probe. Until that happens, what I'd
suggest doing is to just manually scan your high lun. I'll see if I can
come up with a REPORT_LUNS patch, if anyone is willing to play guinea
pig. For the sake of safety with older broken SCSI devices, I might
limit it to working only with FC initiators, only only with devices that
report SCSI-4 or higher. We'll have to play with that.
Scott
More information about the freebsd-scsi
mailing list