| There is a hardcoded "proc0" reference to a processor name in AIX in the following files: lib/facter/resolvers/aix/architecture_resolver.rb
spec/facter/resolvers/aix/architecture_resolver_spec.rb
spec/facter/resolvers/aix/processors_spec.rb
spec/fixtures/processors_cuat
spec/fixtures/processors_cudv If a processor with this name is not present on the system, executing facter produces the following errors (on facter 2.5.1 that we actually use in our environment): lsattr: 0514-519 The following device was not found in the customized
{{ device configuration database:}}
{{ proc0}} I understand that facter 4 does not use lsattr command anymore, but queries the ODM instead. Nevertheless the hardcoded "proc0" in the code suggests that the issue is present in newest version as well. The issue If VCPU assignment for an AIX LPAR is reduced, it can happen that proc0 is deleted or unconfigured (set to the Defined state). This would lead to the following outcomes:
- proc0 deleted: unable to determine system architecture because the expected device "proc0" is not there
- proc0 Defined: might detect architecture incorrectly. This can happen for example if proc0 was unconfigured (set to Defined) on one architecture machine (e.g. POWER8), and then moved to different one (e.g. POWER9). The details of the Defined processor resource will still show POWER8, which is incorrect.
Example:
[root@sibwi110:/home/root(22)]# lsdev | grep proc | head 2proc0 Available 00-00 Processorproc2 Defined 00-02 Processor[root@sibwi110:/home/root(23)]# lsattr -El proc0 }}{{frequency 4190000000 Processor Speed Falsesmt_enabled true Processor SMT enabled Falsesmt_threads 8 Processor SMT threads Falsestate enable Processor state Falsetype PowerPC_POWER8 Processor type False <----- current/correct architecture[root@sibwi110:/home/root(24)]# lsattr El proc2frequency 4208000000 Processor Speed Falsesmt_enabled true Processor SMT enabled Falsesmt_threads 2 Processor SMT threads Falsestate enable Processor state Falsetype PowerPC_POWER6 Processor type False <---- wrong, recorded on previous machine{{[root@sibwi110:/home/root(25)]# }}
Proposed solution In order to mitigate this, I suggest to replace the hardcoded "proc0" by a dynamic value, which can be queried in the ODM. All active processors (in Available state) will report the same correct architecture, therefore it's enough to query just one of them. The active (i.e. Available) processors can be identified by "status = 1" value in CuDv ODM object class. A command line example to do this could be: odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1 For example: [root@sibwi110:/home/root(31)]# odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1
{{ name = "proc0"}} Another example on a server where "proc0" does not exist: {{[root@aix-lpar:/home/root(3)]# lsdev | grep proc }}
proc4 Defined 00-04 Processor
proc8 Available 00-08 Processor
[root@aix-lpar:/home/root(4)]# odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1
{{ name = "proc8"}} For reference, here are the full stanzas on the latter LPAR: [root@aix-lpar:/home/root(5)]# odmget -q "PdDvLn = processor/sys/proc_rspc" CuDv CuDv:
name = "proc4"
}}{{status = 0
}}{{chgstatus = 3
}}{{ddins = ""
}}{{location = "00-04"
}}{{parent = "sysplanar0"
}}{{connwhere = "P4"
}}{{PdDvLn = "processor/sys/proc_rspc" CuDv:
}}{{name = "proc8"
}}{{status = 1
}}{{chgstatus = 2
}}{{ddins = ""
}}{{location = "00-08"
}}{{parent = "sysplanar0"
}}{{connwhere = "P8"
}}{{ PdDvLn = "processor/sys/proc_rspc" |
