> On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer <free...@omnilan.de> wrote: > > 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 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 functionality should be properly documented in the driver. Scott _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
