From owner-svn-src-all@freebsd.org Thu Nov 10 07:54:56 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 6B6F1C39450; Thu, 10 Nov 2016 07:54:56 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0C4E51; Thu, 10 Nov 2016 07:54:55 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id uAA7smNu002920; Thu, 10 Nov 2016 08:54:48 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 55CB1125; Thu, 10 Nov 2016 08:54:48 +0100 (CET) Message-ID: <582427C7.5020007@omnilan.de> Date: Thu, 10 Nov 2016 08:54:47 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Scott Long CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r308217 - in head/sys/dev: mpr mps References: <201611021513.uA2FDPk6062463@repo.freebsd.org> <581C5249.2060104@omnilan.de> <161EBBC5-F642-4A05-9361-179B74CDA50A@samsco.org> In-Reply-To: <161EBBC5-F642-4A05-9361-179B74CDA50A@samsco.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 10 Nov 2016 08:54:52 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) 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: Thu, 10 Nov 2016 07:54:56 -0000 Bezüglich Scott Long's Nachricht vom 09.11.2016 17:06 (localtime): > >> On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer wrote: … >> 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. >> >> Maybe "-1" should be mentioned with sysctl decription, otherwise this is >> another very hard to find/influence behaviour. >> >> > > 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’t 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’s > more of a problem than I estimated? Anyways, sounds like this new I haven't had too much diversity regarding Fusion-MPT and this mapping problem has never hit me yet, so I can't help estimating the severity of that specific problem. But I think I haven't described clearly that I'm having da(4)-numbering problems which are not directly enclosure-mapping related (at least not related to the nvram mapping page), but which hopefully could be worked arround the same way: I frequently had problems replacing drives due to the eternal targetID assigning (every drive with a new/unknown serial gets a consecutive targetID regardless of the enclosure-slot or the number of attached drives). I guess this is stored in a completely different NVRAM page than the enclosure-mapping page. Your patch is intended to solve problems with invalid/absent enclosure-mapping page, but I guess I'll sooner or later need to try the "hw.mpr.use_phy_num=-1" sysctl to hopefully overwrite the targetID++ assigning, which causes "wholes" every time a drive gets replaced. In that case it's just a cosmetic problem, but when rearranging old and new drives on the same controller, it can cause severe confusion for the admins – leading to fatal mistakes. And migrating disks to new controller/chassis is even more problematic if the host had hard wired da(4) assignins via device.hints. I couldn't search the driver to find out if the "save eternal targetID in nvram page N" is really present and not firmware-only induced, but since I saw a different behaviour on windows, I guess it is. I could circumvent the problem by simply using IR firmware since it is only active when mps(4) runs IT firmware. But having a way to disable "save eternal targetID in nvram page N" for mps(4)-IT (via sysctl, and possibly for mpr/mpt also) would be very welcome. Top on my wishlist was extending mpsutil(8) to be able to list and selectively delete single serial-targetID mappings, but I haven't even found a way to do that with any vendor provided tool, not even with LSIUtil – where I can at least erase _all_ mappings. > functionality should be properly documented in the driver. Thanks for your continuous supprt/help/improvements! -Harry