From owner-svn-src-all@freebsd.org Wed Nov 9 16:06:55 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BECEC379B4; Wed, 9 Nov 2016 16:06:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from mail.samsco.org (suzi.samsco.org [96.84.242.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA71ADD; Wed, 9 Nov 2016 16:06:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from localhost (localhost [192.168.254.3]) by mail.samsco.org (Postfix) with ESMTP id D4A9215C1867E; Wed, 9 Nov 2016 16:06:47 +0000 (UTC) Received: from mail.samsco.org ([192.168.254.3]) by localhost (mail.samsco.org [192.168.254.3]) (maiad, port 10024) with ESMTP id 82995-09; Wed, 9 Nov 2016 16:06:47 +0000 (UTC) Received: from [172.19.248.94] (unknown [104.153.224.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: scottl@samsco.org) by mail.samsco.org (Postfix) with ESMTPSA id 172DD15C1867C; Wed, 9 Nov 2016 16:06:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308217 - in head/sys/dev: mpr mps From: Scott Long In-Reply-To: <581C5249.2060104@omnilan.de> Date: Wed, 9 Nov 2016 09:06:29 -0700 Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <161EBBC5-F642-4A05-9361-179B74CDA50A@samsco.org> References: <201611021513.uA2FDPk6062463@repo.freebsd.org> <581C5249.2060104@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3251) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 16:06:55 -0000 > On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Scott Long's Nachricht vom 02.11.2016 16:13 = (localtime): >> Author: scottl >> Date: Wed Nov 2 15:13:25 2016 >> New Revision: 308217 >> URL: https://svnweb.freebsd.org/changeset/base/308217 >>=20 >> Log: >> Add a fallback to the device mapper logic. We've seen systems in = the field >> that are apparently misconfigured by the manufacturer and cause the = mapping >> logic to fail. The fallback allows drive numbers to be assigned = based on the >> PHY number that they're attached to. Add sysctls and tunables to = overrid >> this new behavior, but they should be considered only necessary for = debugging. >=20 > Thanks a lot, this is welcome not only for debugging! >=20 > I had a hard time finding out how to get rid of static > driveserial-targetID assigning. > And more surprising, this affects only IT-fw. When using the same > controller in IR-mode, mapping is done (correctly) slot-based. > In IT-mode, every drive got a consecutive target ID which was static, > and even persistent over firmware updates. There's only one = possibility > with LSIUtil(1.71) to erase /"persitent non-manufacturing config = pages/". > But I guess this hard drive-targetID assigning is triggered by the > driver, namely the mps(4) in FreeBSD. > I did quick tests on windows and IT-mode, where I think I saw slot (or > Phy?) based assigning. >=20 > If it's really mps(4) who decides to store driveserial-targetID > numbering in the /"persitent non-manufacturing config pages/" of the > controller, mpsutil(8) should be able to reset. Otherwise replacing > failed drives, or - even mor confusing - rearranging drive/zpool = layouts > is very unsatisfying. >=20 > Maybe "-1" should be mentioned with sysctl decription, otherwise this = is > another very hard to find/influence behaviour. >=20 >=20 Thanks for the feedback. For the record, this problem happens on a Supermicro X10SDV-7TP4F motherboard. It appears that the support logic around the LSI controller is mis-configured to show the SAS ports being part of an enclosure with 0 slots, instead of 8. This confuses the device mapper logic in the driver that activates if the controller = NVRAM doesn=E2=80=99t specify a pre-existing mapping. Typically this is not = the default, the NVRAM persistent mappings are the default and are used by the = driver, so I considered this problem to be unique to our deployment. Maybe = it=E2=80=99s more of a problem than I estimated? Anyways, sounds like this new functionality should be properly documented in the driver. Scott