From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 12:19:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31472106566B for ; Mon, 13 Feb 2012 12:19:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id D02E88FC0C for ; Mon, 13 Feb 2012 12:19:19 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZQHd1i00327AodY51QKKfW; Mon, 13 Feb 2012 12:19:19 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id ZQKJ1i0091t3BNj3fQKKKC; Mon, 13 Feb 2012 12:19:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7A504102C1E; Mon, 13 Feb 2012 04:19:17 -0800 (PST) Date: Mon, 13 Feb 2012 04:19:17 -0800 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20120213121917.GA71490@icarus.home.lan> References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> <4F38EFE2.7010905@gmail.com> <20120213114941.GA71078@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213114941.GA71078@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , "Desai, Kashyap" Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 12:19:20 -0000 On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: > > Ok so it is not the mps driver who does the naming but cam, and that > > also has changed on 9.0 Stable. > > Well i use gpart labels for the pool, so i can use the gpart labels > > to yank the right disk. > > But it would be nicer if there was some kind of logic in the > > numbering of the devices. > > "Wire them down" in FreeBSD using loader.conf variables and this issue > will cease to be a problem. Example is below, despite being for SATA > with AHCI -- really doesn't matter, just change the appropriate bits and > it should be fine for you. > > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" To be more specific: please see the CAM(4) man page and look at some of the example hint settings shown there. In your case I believe you'd want the below (which is a static map that matches your provided dmesg in the previous mail). If you want different device names tied to the different targets, it should be pretty obvious what to change. hint.scbus.0.at="mps0" hint.da.0.at="scbus0" hint.da.0.target="8" hint.da.0.unit="0" hint.da.1.at="scbus0" hint.da.1.target="9" hint.da.1.unit="0" hint.da.2.at="scbus0" hint.da.2.target="10" hint.da.2.unit="0" hint.da.3.at="scbus0" hint.da.3.target="11" hint.da.3.unit="0" hint.da.4.at="scbus0" hint.da.4.target="12" hint.da.4.unit="0" hint.da.5.at="scbus0" hint.da.5.target="13" hint.da.5.unit="0" hint.da.8.at="scbus0" hint.da.8.target="19" hint.da.8.unit="0" hint.da.9.at="scbus0" hint.da.9.target="20" hint.da.9.unit="0" hint.da.11.at="scbus0" hint.da.11.target="22" hint.da.11.unit="0" hint.da.12.at="scbus0" hint.da.12.target="23" hint.da.12.unit="0" hint.da.13.at="scbus0" hint.da.13.target="24" hint.da.13.unit="0" hint.da.14.at="scbus0" hint.da.14.target="27" hint.da.14.unit="0" hint.da.15.at="scbus0" hint.da.15.target="28" hint.da.15.unit="0" Naturally you can do the same for your AHCI controller bits too, though understand that each channel/port on the controller there matches to a separate scbusX unit, so you may want to start the numbering higher (in the case the LSI controller could ever have more scbusX entries added; e.g. LVMs or similar -- not sure how those are implemented there, but it doesn't matter, you get my drift I hope). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |