Date: Fri, 04 Nov 2016 10:18:01 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Scott Long <scottl@freebsd.org> 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 Message-ID: <581C5249.2060104@omnilan.de> In-Reply-To: <201611021513.uA2FDPk6062463@repo.freebsd.org> References: <201611021513.uA2FDPk6062463@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich 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 > > 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. Thanks a lot, this is welcome not only for debugging! 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. 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, -harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?581C5249.2060104>