svn commit: r308217 - in head/sys/dev: mpr mps
Scott Long
scottl at samsco.org
Wed Nov 9 16:06:55 UTC 2016
> On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer <freebsd at 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
More information about the svn-src-head
mailing list