Date: Sat, 08 Mar 2008 08:57:27 -0700 From: Scott Long <scottl@samsco.org> To: "Kenneth D. Merry" <ken@kdm.org>, d_elbracht <d_elbracht@ecngs.de> Cc: freebsd-scsi@freebsd.org Subject: Re: AW: AW: only 8 LUNs on MPT Message-ID: <47D2B767.5040403@samsco.org> In-Reply-To: <20080308010739.GA4855@nargothrond.kdm.org> References: <001301c88056$76745f60$639049d9@EC1a> <47D1605A.8030505@samsco.org> <003801c88069$57510cb0$639049d9@EC1a> <47D16578.4070104@samsco.org> <20080308010739.GA4855@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47D2B767.5040403>