Date: Sat, 8 Mar 2008 17:57:14 +0100 From: "d_elbracht" <d_elbracht@ecngs.de> To: "'Scott Long'" <scottl@samsco.org>, "'Kenneth D. Merry'" <ken@kdm.org> Cc: freebsd-scsi@freebsd.org Subject: AW: AW: AW: only 8 LUNs on MPT Message-ID: <008701c8813d$75b84d60$639049d9@EC1a> In-Reply-To: <47D2B767.5040403@samsco.org> References: <001301c88056$76745f60$639049d9@EC1a> <47D1605A.8030505@samsco.org> <003801c88069$57510cb0$639049d9@EC1a> <47D16578.4070104@samsco.org> <20080308010739.GA4855@nargothrond.kdm.org> <47D2B767.5040403@samsco.org>
index | next in thread | previous in thread | raw e-mail
Yes, I am willing to play guinea pig :) the Contoller (LSI 3801E) is not FC, it is SAS if my recollection works, we had a similar issue (unsolved) with Qlogic FC 2312, limited to 16 LUNs the Code there is: isp_freebsd.c: cpi->max_lun = ISP_MAX_LUNS(isp) - 1; 'camcontrol inq da32' gives pass32: <IFT A24F-G2224-1 347B> Fixed Direct Access SCSI-3 device pass32: Serial Number 0C04C96131C15A00 200.000MB/s transfers , Command Queueing Enabled so SCSI-4 Limitation may not be all. Dieter > -----Ursprüngliche Nachricht----- > Von: Scott Long [mailto:scottl@samsco.org] > Gesendet: Samstag, 8. März 2008 16:57 > An: Kenneth D. Merry; d_elbracht > Cc: freebsd-scsi@freebsd.org > Betreff: Re: AW: AW: only 8 LUNs on MPT > > 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 >help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008701c8813d$75b84d60$639049d9>