Date: Thu, 10 Nov 2016 08:54:47 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Scott Long <scottl@samsco.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: <582427C7.5020007@omnilan.de> In-Reply-To: <161EBBC5-F642-4A05-9361-179B74CDA50A@samsco.org> References: <201611021513.uA2FDPk6062463@repo.freebsd.org> <581C5249.2060104@omnilan.de> <161EBBC5-F642-4A05-9361-179B74CDA50A@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Scott Long's Nachricht vom 09.11.2016 17:06 (localtime): > >> On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer <freebsd@omnilan.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?582427C7.5020007>