#
4fa67aa1 |
| 03-Feb-2025 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: update latest spec and reformat
Copy the latest format file from the docs repository and apply.
Change-Id: If152304b21dd2daaa2f79255a4f98218615efb05 Signed-off-by: Patrick Williams <p
clang-format: update latest spec and reformat
Copy the latest format file from the docs repository and apply.
Change-Id: If152304b21dd2daaa2f79255a4f98218615efb05 Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
show more ...
|
#
dfddd648 |
| 16-Aug-2024 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: re-format for clang-18
clang-format-18 isn't compatible with the clang-format-17 output, so we need to reformat the code with the latest version. The way clang-18 handles lambda forma
clang-format: re-format for clang-18
clang-format-18 isn't compatible with the clang-format-17 output, so we need to reformat the code with the latest version. The way clang-18 handles lambda formatting also changed, so we have made changes to the organization default style format to better handle lambda formatting.
See I5e08687e696dd240402a2780158664b7113def0e for updated style. See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.
Change-Id: Ica590f8613f1fb89ab1ca676ac51c1cc7e38d67f Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
show more ...
|
#
4c62fc77 |
| 14-Feb-2024 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Add fan_frus_with_nonfunc_rotors cause
Create a new power off rule to power off when a specific number of fan FRUs have nonfunctional rotors. With this rule failing rotors can be treated d
monitor: Add fan_frus_with_nonfunc_rotors cause
Create a new power off rule to power off when a specific number of fan FRUs have nonfunctional rotors. With this rule failing rotors can be treated differently when they are spread across fans FRUS than when they are within the same fan FRU.
For example, if both rotors of a 2 rotor fan fail the system can stay up, but if 2 rotors in separate fans fail then the system could be made to power off.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Ia1d13596a9e8a6e3a361e5b631699a3c80e36fb8
show more ...
|
#
5e15c3ba |
| 20-Oct-2023 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: copy latest and re-format
clang-format-17 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest
clang-format: copy latest and re-format
clang-format-17 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest .clang-format from the docs repository and reformat the repository.
Change-Id: I3e9e6350864ac267819a4b8d670bef7d3746976e Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
show more ...
|
#
fbf4703f |
| 17-Jul-2023 |
Patrick Williams <patrick@stwcx.xyz> |
use std::format instead of fmt::format
The std::format is sufficient for the uses in this repository except for in one file (override_fan_target.cpp, since P2286 isn't supported by GCC yet). Switch
use std::format instead of fmt::format
The std::format is sufficient for the uses in this repository except for in one file (override_fan_target.cpp, since P2286 isn't supported by GCC yet). Switch to std::format whenever possible.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Change-Id: Ib2576fb530a4d7ce238e1b0bd95b40b476ec2107
show more ...
|
#
f724c16b |
| 10-May-2023 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Support a separate upper deviation
Add an optional 'upper_deviation' field to the fan monitor config and if supplied it will be used for the allowed deviation when the fan value is over the
monitor: Support a separate upper deviation
Add an optional 'upper_deviation' field to the fan monitor config and if supplied it will be used for the allowed deviation when the fan value is over the target. If not supplied it will work as today and the single deviation value will be used for both the upper and lower bounds.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I085dc1996832e79b94bd1df3a05681d107f466eb
show more ...
|
#
18fb12b8 |
| 09-May-2023 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Change Fan/Sensor def tuples to structs
The tuples were big and hard to read/use. Change them to structs so the members are always named.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
monitor: Change Fan/Sensor def tuples to structs
The tuples were big and hard to read/use. Change them to structs so the members are always named.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I79826563faf44636b251e614f45ff86f1e02c607
show more ...
|
#
61b73296 |
| 10-May-2023 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: copy latest and re-format
clang-format-16 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest
clang-format: copy latest and re-format
clang-format-16 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest .clang-format from the docs repository and reformat the repository.
Change-Id: I152f141a5e8343b92b5ce81d3ca16eec77b5606b Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
show more ...
|
#
27cc39f1 |
| 20-Sep-2022 |
Chau Ly <chaul@amperecomputing.com> |
monitor: Support target_path option in configuration file
The target path containing the interface xyz.openbmc_project.control.FanPwm or xyz.openbmc_project.control.FanSpeed can be different between
monitor: Support target_path option in configuration file
The target path containing the interface xyz.openbmc_project.control.FanPwm or xyz.openbmc_project.control.FanSpeed can be different between phosphor-hwmon and dbus-sensor.
In phosphor-hwmon, it is "/xyz/openbmc_project/sensors/fan_tach/". In dbus-sensor, it is "/xyz/openbmc_project/control/fanpwm/".
This commit supports making this path configurable via "target_path" as a full object path. By default, it is the same as the fan tach object path.
Signed-off-by: Chau Ly <chaul@amperecomputing.com> Change-Id: I2658a462dd49a98ad77d684f2927e6ccae21cd15
show more ...
|
#
808d7fe8 |
| 13-Jun-2022 |
Mike Capps <mikepcapps@gmail.com> |
meson support: remove code warnings 1
This commit contains code changes necessary to support the increased warning level from Meson builds. Most changes are for unused variables.
To keep the review
meson support: remove code warnings 1
This commit contains code changes necessary to support the increased warning level from Meson builds. Most changes are for unused variables.
To keep the review size manageable, this commit contains only monitor and presence changes (and top-level json_config.hpp).
Signed-off-by: Mike Capps <mikepcapps@gmail.com> Change-Id: I7280b512c54e8d5aeba3300764a239f3dcbab14d
show more ...
|
#
78182482 |
| 23-Jun-2022 |
Mike Capps <mikepcapps@gmail.com> |
monitor: fix undefined behavior
A recent static analysis check revealed a use-after-free condition in json_parser.cpp. This fixes the undefined behavior.
Signed-off-by: Mike Capps <mikepcapps@gmail
monitor: fix undefined behavior
A recent static analysis check revealed a use-after-free condition in json_parser.cpp. This fixes the undefined behavior.
Signed-off-by: Mike Capps <mikepcapps@gmail.com> Change-Id: I62b82b4982386d14e6ee7225b3ab6f3628e2a416
show more ...
|
#
8a8aa442 |
| 19-Nov-2021 |
Matthew Barth <msbarth@us.ibm.com> |
monitor: Add ignoring feedback sensors above allowed max
There may be situations where fan rotor feedback speeds above the allowed range could be ignored, essentially ignoring any overspeed detectio
monitor: Add ignoring feedback sensors above allowed max
There may be situations where fan rotor feedback speeds above the allowed range could be ignored, essentially ignoring any overspeed detections. This adds an optional `ignore_above_max` attribute to the fan sensors that can be added, set to 'true', to ignore marking that fan sensor as nonfunctional when its above the allowed max. Without this attribute, the fan sensor must remain within the allowed min/max range to be deemed functional. This is the default behavior.
Change-Id: I4876b4c1963a8a1becd55732ca19496f5df6b003 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
show more ...
|
#
a3584bd2 |
| 29-Mar-2021 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Support set_func_on_present
The set_func_on_present JSON field determines if the fan FRU and rotors should be set to functional immediately when a fan plug is detected. It is optional in t
monitor: Support set_func_on_present
The set_func_on_present JSON field determines if the fan FRU and rotors should be set to functional immediately when a fan plug is detected. It is optional in the JSON file, and defaults to false if not present.
When this is false, a fan will have to spin back up again before it is set back to functional, meaning that if the new fan is faulty and never spins up there may not be another error created. If a faulty fan is plugged when this setting is true, then an error will be created as soon as the configuration allows.
In some system configurations, the functional status on the fan FRU may also control LED status, so setting the FRU to functional on the plug would also turn off a fault LED, which is a desired behavior in the systems that do this.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: If1a8e62a7b390e8137353a7ecc423a60df138315
show more ...
|
#
623635c6 |
| 29-Mar-2021 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Create count timer
When the method for monitoring fan speeds is set to 'count', which is when an up/down counter is used determine when a fan should be considered faulted/nonfunctional, the
monitor: Create count timer
When the method for monitoring fan speeds is set to 'count', which is when an up/down counter is used determine when a fan should be considered faulted/nonfunctional, there needs to be some interval at which the speeds are checked and the count is changed if necessary. Otherwise, if the checks just happened in the tach changed callback as they do today, then a fan with a non-changing rotor speed would never trigger a check.
This commit creates a new timer in the Fan class that is constantly running when the monitor is active if any of the fan's sensors use this mode. In the expiration function, the sensors' tach targets will be compared to their input values and the error count will be incremented/decremented as was previously happening in the tach changed callback.
The interval to use is read from a new 'count_interval' property in the JSON, which defaults to 1 if not present and the count method is enabled.
The timer is started in the startMonitor function, and stopped when a power off is detected.
This commit also added some DEBUG journal traces when the counter on a sensor changes values to help with debugging the new code, and so it can be enabled on a system if desired by enabling debug level tracing.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I238606e95bb91df93afd6ec7c00bd0577bc603f2
show more ...
|
#
4c4de263 |
| 17-Feb-2021 |
Matthew Barth <msbarth@us.ibm.com> |
monitor: Deviation attribute details(docs) & enforce range
The `deviation` attribute contains the +/- percentage allowed for the sensors to deviate from any requested target.
Also enforcing the `de
monitor: Deviation attribute details(docs) & enforce range
The `deviation` attribute contains the +/- percentage allowed for the sensors to deviate from any requested target.
Also enforcing the `deviation` value provided in the JSON configuration is between 0 and 100.
Signed-off-by: Matthew Barth <msbarth@us.ibm.com> Change-Id: I3064e9b407c2edec7fb0fd36a2d1cd3f53d3e397
show more ...
|
#
69f2f48e |
| 20-Oct-2020 |
Jolie Ku <jolie_ku@wistron.com> |
monitor: Add up/down count fault detection
Create an up/down count fault determination algorithm that could be used in place of the current timer based outOfRange() function. The up/down count is a
monitor: Add up/down count fault detection
Create an up/down count fault determination algorithm that could be used in place of the current timer based outOfRange() function. The up/down count is a different method for determining when a fan is faulted by counting up each iteration a rotor is out of spec and removing those counts when the rotor returns within spec.
Tested: 1. Remove a fan and run Mihawk, the counter add 1 when sensor is out of spec, and replaced the fan back before hit the threshold, the counter decrement back to 0. 2. Remove a fan, counter add 1 and mark the removed fan as nonfunctional when counter reaches the threshold, and Replaced the fan back, counter will decrement back to 0 and fan back to functional.
Change-Id: I632dd2c7553b007beb7ae6bb694a590d2cfc2a1c Signed-off-by: Jolie Ku <jolie_ku@wistron.com> Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
show more ...
|
#
ac1efc11 |
| 27-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Re-log fan error on a power off
In the case where a power off rule runs to completion and powers off the system due to either missing or faulted fans, at the point of power off re-post the
monitor: Re-log fan error on a power off
In the case where a power off rule runs to completion and powers off the system due to either missing or faulted fans, at the point of power off re-post the event log for the previous fan error.
This way, there can be an error associated with the power off, because depending on the power off rule delays the original error could have happened several minutes or more in the past.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I1a38062cf75ffd4a11baa417ef3983b6c1a47ada
show more ...
|
#
27f6b686 |
| 27-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Event logs for missing fans
This commit adds the code to create event logs calling out the fan when it has been missing for a certain amount of time.
This is basically identical to the fun
monitor: Event logs for missing fans
This commit adds the code to create event logs calling out the fan when it has been missing for a certain amount of time.
This is basically identical to the functionality that the fan presence application in this repo provides, but with it in this application all fan errors are created from the same place. This will become important when there is a power off due to a fan missing and the error for that needs to be re-committed at power off time so it can be shown as the cause of the power off.
The functionality is configured in the JSON:
fan_missing_error_delay: Defines the number of seconds a fan must be missing with power on before an error will be created. If this isn't present in the JSON, then errors will not be created at all.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I76de9d8d1bf6e283560b1ce46e70f84522e2d708
show more ...
|
#
f13b42e2 |
| 26-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Event logs for nonfunc fan sensors
This commit adds the code to create event logs calling out the fan when fan sensors have been nonfunctional for a certain amount of time.
This functional
monitor: Event logs for nonfunc fan sensors
This commit adds the code to create event logs calling out the fan when fan sensors have been nonfunctional for a certain amount of time.
This functionality is configured in the JSON, and will only be enabled if the 'fault_handling' JSON section is present. It uses the following new JSON parameters:
nonfunc_rotor_error_delay (per fan): This says how many seconds a fan sensor must be nonfunctional before the event log will be created.
num_nonfunc_rotors_before_error (under fault_handling): This specifies how many nonfunctional fan rotors there must be at the same time before an event log with an error severity is created for the rotor. When there are fewer than this many nonfunctional rotors, then event logs with an informational severity will be created.
A new FanError class is used to create the event logs. It adds the Logger output as FFDC, plus any JSON data that is passed in with the commit() API. It uses CALLOUT_INVENTORY_PATH in the AdditionalData property to specify the faulted fan FRU.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I365114357580b4f38ec943a769c1ce7f695b51ab
show more ...
|
#
ae1f8efe |
| 14-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Allowing ignoring fan FRU func status
Make the 'num_sensors_nonfunc_for_fan_nonfunc' JSON entry be optional, and if it isn't present then don't set the parent fan FRU inventory object funct
monitor: Allowing ignoring fan FRU func status
Make the 'num_sensors_nonfunc_for_fan_nonfunc' JSON entry be optional, and if it isn't present then don't set the parent fan FRU inventory object functional state when the tach sensor functional states change.
This is necessary because on some systems some other entity will be managing the FRU level functional state.
This also adds a trace when the tach sensor functional state changes, since if the FRU functional state updating is turned off then the existing traces won't appear.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I1be9cc335c15a78d342e2e7ea4e5108a66d29de3
show more ...
|
#
f06ab07c |
| 14-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Create PowerOffRules class
This class contains a PowerOffCause and a PowerOffAction. It provides a check() method that takes the FanHealth map which it then checks against the cause. If t
monitor: Create PowerOffRules class
This class contains a PowerOffCause and a PowerOffAction. It provides a check() method that takes the FanHealth map which it then checks against the cause. If the cause is satisfied, it then starts the power off action. It provides a cancel method that will force cancel a running action in the case that the object owner detects a system power off and so doesn't need to run this power off anymore.
The class's configuration data is read from the JSON config file.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I5c0c168591d6d62c894c4d036ec762797fd759af
show more ...
|
#
b0412d07 |
| 12-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
monitor: Use only init mode when using JSON
Fan monitor is currently split into 2 modes - 'init' which is used right after a power on, and 'monitor', which is used later after the fans-ready target
monitor: Use only init mode when using JSON
Fan monitor is currently split into 2 modes - 'init' which is used right after a power on, and 'monitor', which is used later after the fans-ready target is started. Normally, the 'init' mode just sets the fans to functional and then exits, and the real monitoring work is done in the 'monitor' mode.
In the future this application will need to be able to check for fan problems as soon as it starts up after power on so that it can handle shutting down due to missing fans. To prepare for this, move all functionality into the init mode, and just exit immediately when called to run in the monitor mode. Only do this when compiled to use the JSON configuration, as this is new and I don't want to change how the existing YAML setups work.
This also creates a new 'monitor_start_delay' entry in the JSON to say how long to wait after startup before actually doing any sensor monitoring, which then gives the same behavior as how the monitor mode would delay by waiting for the fan control ready target, which itself is started by fan control --init after a hardcoded delay. This field is optional to preserve backwards compatibility and defaults to 0s.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I623a233f50233e734f50cd9e80139c60467518d8
show more ...
|
#
8a0c2327 |
| 17-Jun-2020 |
Matthew Barth <msbarth@us.ibm.com> |
monitor: `optional` no longer experimental
Change-Id: I29e4fa5cfdf5cefe1af548fd5af2a54d08682a11 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
#
3ad14346 |
| 08-Jun-2020 |
Matthew Barth <msbarth@us.ibm.com> |
monitor:JSON: Parse fan monitoring conditions
Optional conditions can be used to include monitoring a fan or not based on the results of the condition function configured. These condition functions
monitor:JSON: Parse fan monitoring conditions
Optional conditions can be used to include monitoring a fan or not based on the results of the condition function configured. These condition functions have their own required set of parameters, so parsing the JSON for these conditions are done per supported condition function. This adds the JSON parsing support for the current condition functions.
Tested: `propertiesMatch` JSON parameters parsed into condition function Any required parameters missing throws an exception The `propertiesMatch` condition functions the same using JSON
Change-Id: I0f843951f4e83f2a5d44068820694010538788c1 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
show more ...
|
#
22ab93b4 |
| 08-Jun-2020 |
Matthew Barth <msbarth@us.ibm.com> |
monitor:JSON: Parse fan definitions
Parse and create the list of fan definitions for monitoring from a JSON configuration file.
Tested: Fan definition list created same as from YAML Any req
monitor:JSON: Parse fan definitions
Parse and create the list of fan definitions for monitoring from a JSON configuration file.
Tested: Fan definition list created same as from YAML Any required parameters missing cause a runtime exception
Change-Id: Iafa194f01a48ed3445c5da6187db62cb4d2672d7 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
show more ...
|