summaryrefslogtreecommitdiffstats
path: root/monitor
Commit message (Collapse)AuthorAgeFilesLines
* Throw custom exceptions on D-Bus method failuresMatt Spinler2018-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | All 3 fan applications - control, monitor, and presence have cases where it is expected that a getProperty call may fail because a sensor is missing. While the applications already handle this, the InternalFailure exception that was being thrown by the underlying call generates log entries that make it look like something bad happened. The custom exceptions now being thrown do not log anything on creation, but store all of the failing information so that any callers could still log the info if they wanted to. Tested: Boot a water cooled Witherspoon and see the fan presence and monitor applications not look like they are failing. Boot a system without the fan hwmon running, and see fan-control-init still show the fails. Change-Id: Ifd8ad6e3deb492bbaf33f12c7258125dce1e5ea8 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add generation of propertiesMatch conditionMatthew Barth2018-05-032-1/+50
| | | | | | | | | | | | | | | | | Update the mako template to generate conditions within the FanDefinition sections when a condition is defined for a fan. Each supported condition function's parameters are generated within a `getCondParams` mako method, allowing easy support of additional conditions with differing parameters. Tested: A given condition's function and parameters generate correctly No condition function is generated on a fan where not defined Resolves: openbmc/openbmc#2976 Change-Id: I3f0b30702fdcef6749929d85543270863eb26381 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Support optional conditions on creating fansMatthew Barth2018-05-035-2/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the functional infrastructure to optionally attach a condition function to a fan definition. When a condition is defined on a fan, it must be true for a fan's associated functional properties to be created. When the given condition fails, that fan's functional properties will not be created by fan monitor. A fan without a defined condition will have all of its associated functional properties created. Example of generated condition (generation commit to follow): make_condition(condition::propertiesMatch( std::vector<PropertyState>{ PropertyState{ PropertyIdentity{ "/xyz/openbmc_project/inventory/system/chassis", "xyz.openbmc_project.Inventory.Decorator.CoolingType", "WaterCooled" }, static_cast<bool>(false) } } )), Tested: Fan functional properties are not created when a condition fails Fan functional properties are created when condition passes Fan functional properties are created when no condition exists Change-Id: I9ced2e520d2f97e6655c9417970b3e976d78fef4 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Handle timer expiration on state changesMatthew Barth2018-03-011-19/+17
| | | | | | | | | | | | | | | | | | Update to start all tach sensor functional state change timers on a fan where the corresponding state and inventory is updated when the timer expires. Only start the timer in nonfunctional mode when a tach sensor is out of range and is currently functional and start the functional mode timer when its in range and currently nonfunctional. Tested: Tach sensors are marked nonfunctional as normal. Tach sensors are updated to functional after 5sec(yaml test value) Nonfunctional timer is cancelled if fan returns within spec Functional timer is cancelled if fan returns out of spec Change-Id: I88622d07d8713f88e8070940a4bd96046a053fb5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Define a mode for tach sensor timerMatthew Barth2018-03-014-14/+67
| | | | | | | | | | | | | | Use a single timer on the tach sensors for delaying both nonfunctional and functional state changes by declaring what mode the timer is in. Since a fan is either transitioning from a functional state to a nonfunctional state or vice-versa, enabling the timer in the mode requested allows the user to define a delay for both of these transition states. Tested: Current nonfunctional timer delay operates the same Change-Id: I0c165355d41d27e1906918953e5226968062ee16 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add tach sensor functional delayMatthew Barth2018-03-016-4/+21
| | | | | | | | | | | | | | Add ability to define a delay to marking a tach sensor as functional when it transitions from a nonfunctional state. Essentially this gives the option to wait a given amount of time that a tach sensor must be within the allowed deviation before being updated to functional. Default functional delay = 0 seconds Tested: Current fan definition values function the same Change-Id: I58bf70d2335e27c06037b755cbee8dae81528a5a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* NonzeroSpeed: Check trust determination sensorsMatthew Barth2018-03-012-6/+11
| | | | | | | | | | | | Only include defined trust determination sensors in checking the group trust. Tested: Current trust group associations & reactions are unchanged Combination of sensors included and excluded in trust determination Change-Id: I0f610b2910ffda849871a9ac9be95f2c056d8248 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Replace tuple with struct for trust sensor groupMatthew Barth2018-03-012-12/+16
| | | | | | | | | | | To simplify sensor and trust access, utilize a struct in place of a tuple for storing the trust group sensors and their inclusion in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: Ifd5cf5d0540a3b2028ccf74e725d8ddd11982aee Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Generate sensor to trust associationMatthew Barth2018-03-013-21/+34
| | | | | | | | | | | | | | | | | Each sensor listed to be associated with a trust group is defined to either be part of the trust group or just affected by the results of the trust group. This is denoted by defining an "in_trust" boolean attribute that will include the sensor in the trust group for determination of trust when true, otherwise only be included in the resulting trust affect when defined as false. When no "in_trust" attribute is given, the sensor is defaulted to be included in the trust group determining trust. Tested: Current trust group associations & reactions are unchanged Change-Id: I717074bc1a32a07dc59f172a4c823c7e2bb84f8c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* optimize: Tach sensors as shared pointersMatthew Barth2018-03-015-13/+12
| | | | | | | | | | | | | The fan and trust group objects should utilize shared pointers to the tach sensor objects. This allows optimizing the storage of additional attributes associated with the tach sensors. e.g. An attribute to declare which sensors should be included in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: I249cc7debf467e8275fae7fa157ce97078b40802 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add target interface for fan monitorLei YU2018-02-266-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | Current fan monitor assumes the use of the FanSpeed interface for fan targets. For fans controlled by pwm, FanPwm interface is added. This commit adds a "target_interface" config parameter, so that user can specify the interface for the fan targets. E.g. - name: fan0 has_target: true target_interface: xyz.openbmc_project.Control.FanPwm This config is optional and defaults to FanSpeed, so the current code will not be affected. Tested: Use this config on Romulus, ensures fan monitor gets fan target from FanPwm interface and works OK. Change-Id: I262a486c335b2b43a46af7abdd0e71e95a133b98 Signed-off-by: Lei YU <mine260309@gmail.com>
* Add factor and offset for fan monitorLei YU2018-02-266-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For fans controlled via pwm, the fan target and speed are different, where the fan target is pwm and the speed is rpm. Usually it is a linear mapping from pwm to rpm. So this commit defines the optional configs, factor and offset for calculating the expected fan speed from target, e.g. - name: fan0 has_target: true factor: 21 offset: 1600 The fan monitor service will calculate expected fan speed as: target * factor + offset The default value is 1 for factor and 0 for offset if they are not defined. Tested: Use this config together with the following commit's changes, test on Romulus and ensures the fan monitor works OK; Without this config, fan monitor always mark fans as non-functional due to the fan speed does not match the pwm value. Change-Id: If5e25368b4530df7a7face9377efb58804db21df Signed-off-by: Lei YU <mine260309@gmail.com>
* Set tach sensor to functional on startMatthew Barth2018-01-304-71/+78
| | | | | | | | | | With the addition of a functional state for each fan rotor tach sensor, these should be set to functional on each power on. This is done during fan monitor init mode when no monitor is done and then again once monitoring mode begins. Change-Id: I3c73c1be5f912c7cee8499f47cc799ac3c20983b Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use setFunctional when tach sensor is constructedMatthew Barth2018-01-231-2/+1
| | | | | Change-Id: I32e30dc8f659172026258ca533099404c90aebbc Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Remove getTargetSpeedMatthew Barth2018-01-232-21/+2
| | | | | | | | The getTargetSpeed function is no longer needed. The tach sensors are used to get the target speed. Change-Id: I5f82b0c3e8104203e2700b22a5488cf63673d181 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* All sensors should return a target speed valueMatthew Barth2018-01-184-28/+44
| | | | | | | | | | | | | All tach sensors associated with a fan should return a target speed sensor from its getTarget function. In the case where a target speed sensor does not exist for the tach sensor, it retrieves and returns the target speed value from the fan where the fan finds the target speed value from a tach sensor the fan contains that provides it. Resolves openbmc/openbmc#2784 Change-Id: Iea5561b0aad6942be52af262c7255c60e5e75c7a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set tach sensor inventory functional stateMatthew Barth2017-12-052-7/+12
| | | | | | | | | | | At startup, initialize the functional state of each tach sensor to true and then update the inventory's functional state to match the tach sensor's functional state. Resolves openbmc/openbmc#2629 Change-Id: If608e4c044d9eeaa3dbdafa22bc89327e323c9a8 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add functional property for each tach sensorMatthew Barth2017-12-054-2/+47
| | | | | | | | | | | | Each fan's tach sensor creates a child inventory object under the fan's inventory path containing the sensor's functional state. This child inventory object path is the fan's path plus the tach sensor's defined id. i.e.) /xyz/openbmc_project/inventory/system/chassis/motherboard/fan0/fan0_0 Change-Id: I0fe5000eadbe55d60b475ccad700b0264ed0ac75 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update fan inventory methodMatthew Barth2017-12-052-43/+12
| | | | | | | | | Use the methods provided within sdbusplus.hpp to update fan inventory along with prepping inventory to be updated for each fan rotor sensor's functional state. Change-Id: I7d3026d289b1dd22cd4e7b4457c4d4396309c0b5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update trust group sensor timer startMatthew Barth2017-11-271-2/+5
| | | | | | | | | | | | | | Trust group sensors' timers should only start when the sensor is currently functional and its target and input do not match. This handles the case where a sensor within a trust group does not get a target set resulting in both the target and input to be zero. At anytime a sensor's target and input are equal, the timer to mark them as nonfunctional should not start. Change-Id: I8e4fd33a5bcbd25854e5954b41646127982eedd3 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* monitor: Start checking tach trustMatt Spinler2017-10-113-2/+27
| | | | | | | | | The Fan class now uses the trust::Manager class to ask if a sensor value is trusted before analyzing its value against the upper and lower limits. Change-Id: I81dd468877873ba84753d76395b4a59129824c0b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Update YAML parser to handle trust groupsMatt Spinler2017-10-113-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It creates a list of group creator lambdas based on the information in the monitor YAML file. These lambdas are called by the manager class to create the trust group instances. A real life example is: const std::vector<CreateGroupFunction> trustGroups { { []() { std::vector<std::string> names{ "fan0_1", "fan1_1", "fan2_1", "fan3_1", }; return std::make_unique<NonzeroSpeed>(names); } }, }; Change-Id: Ia883df35efb86242aae2f8ed7d1714e94e65a6e6 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Update example YAMLMatt Spinler2017-10-111-1/+21
| | | | | | | | Update the YAML documentation with sensor trust information. Change-Id: Ia5407b079b5dcfbd4063cec8dbba032fefa11b6b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Add trust manager classMatt Spinler2017-10-112-0/+151
| | | | | | | | | | | | | | | This class contains the trust groups, and is the interface for asking if a sensor value can be trusted or not. It will also start and stop timers on all sensors in the same group as the timer in question whose trust value just changed. This class will be used by the Fan class in the speed change callback function to check if a sensor is trusted before analyzing its value. Change-Id: I134be095b6b5222f7bc0e457078cf01f75a36219 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Add NonzeroSpeed trust group classMatt Spinler2017-10-111-0/+63
| | | | | | | | | | | | | | | | | This class provides the ability to only trust the sensors in the group if at least one of them has a nonzero speed. It is being used for a system where the tach values for a set of rotors are reported as zero by the fan controller hardware when the other rotor on the fan is moving to a new target speed. As all the fans are set to the same speed at the same time, the rotors in question all report as zeros at exactly the same time, and this is then used to know when the values cannot be trusted. Change-Id: I29a014014bc8455287f90e5b573a856814331a53 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Add tach sensor trust group classMatt Spinler2017-10-113-1/+239
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The trust::Group class is an abstract base class that introduces the concept of knowing if a tach sensor reading can be trusted or not. If it isn't trusted, then it shouldn't be used when calculating if the fan is considered functional or not. It's a group because it supports groups of sensors all having the same trusted status. For example the first use case is a group of sensors cannot be trusted when all of their readings are zero. A group may of course just have 1 sensor in it if required. The class also provides the functionality to start and stop the timers that are used to consider a sensor faulted. The timers would be stopped when a group moves to untrusted, and started when it goes back to the trusted state. Derived classes provide the functionality that actually determines the trust value. The constructor takes the list of sensor names that should be in the group. After the TachSensor classes have been constructed, the registerSensor(sensor) function must be called to add the sensor objects to the group. The checkTrust() function is used to calculate the trust status of the group. Change-Id: Ib4b871c6a186105028d1cc186c49611fb0608325 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Move timer ops into TachSensorMatt Spinler2017-10-022-8/+27
| | | | | | | | | Upcoming commits will touch the TachSensor timer outside of the Fan class, and it will be cleaner to encapsulate the operations in TachSensor. Change-Id: I8584c44eb5dbe6bb93191a006d20dfc37596eeb3 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Create fan monitor init modeMatthew Barth2017-08-235-37/+166
| | | | | | | | | | | | | Allowing fan monitor to run in an init mode will set the fans to a functional state at each poweron for fans that were non-functional at poweroff. Then fan monitor can be started in monitor mode after the fans have ramped up to full speed and can begin being monitored for faults. This also allows for the removal of fan monitor doing a sd_notify prior to fan control starting. Change-Id: I634c9b4ec8bb30860dea54c8abd1cd6c56831d25 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* monitor: Remove static systemd match callbacksBrad Bishop2017-08-032-58/+6
| | | | | | | | Replace static systemd match callback wrappers with lamba methods. Change-Id: Ib8471478824d87483a60f527d29aa2d35ccb833f Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Use sdbusplus::bus::match::rulesBrad Bishop2017-08-031-5/+2
| | | | | Change-Id: I96ed7de07acfc864c497a0130c3e5afab579d21d Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Do not allow TachSensor moveBrad Bishop2017-08-031-2/+4
| | | | | | | | | TachSensor uses the this pointer as the systemd callback context for signal callbacks, which doesn't work with move semantics. Change-Id: I5e58fec9a7edfc457103d8a36f6076d90246f4f0 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Allow missing sensorsBrad Bishop2017-08-033-12/+37
| | | | | | | | Don't count sensors that don't exist as nonfunctional. Let some other application decide if missing sensors are a problem or not. Change-Id: Ie3d438c92df16bfd86ddc86db8a9dd143bf2cfb0 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Remove getServiceBrad Bishop2017-08-032-17/+0
| | | | | | | Remove getService from tach_sensor as it is no longer used. Change-Id: I568afb502379e05e85685d279033ab198c3cc91f Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Use common wrapper methodsBrad Bishop2017-08-031-32/+5
| | | | | | | | Replace the implementation of readProperty with a call to the common property accessor in sdbusplus.hpp. Change-Id: Ic4ba75bad7458a99f3e29c9235e1a54ae62286fe Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* fan-monitor: Capture more data on failureMatt Spinler2017-07-302-1/+12
| | | | | | | | | When a fan gets set to nonfunctional, it is useful to know how fast the rotor was actually going and what the expected speed was. Change-Id: I760d6fa7d193038f9740d241bf4d4d0039020f64 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Avoid Target interface for mapper queriesBrad Bishop2017-07-111-1/+3
| | | | | | | Avoid asking the mapper for the Target interface on sensors that do not have it. Change-Id: I43f61c98291cc15d7daf43d2b01c6b7fa4edfa62
* phosphor-fan-presence elog error exception.Dinesh Chinari2017-06-283-14/+15
| | | | | | | | Implemented elog exception for phosphor fan presence, replacing runtime_errors. Change-Id: I70465060838b2cbaeadccf84ed5924e222ac59e3 Signed-off-by: Dinesh Chinari <chinari@us.ibm.com>
* fan-monitor: use sd_notify(READY=1)Matt Spinler2017-06-261-0/+10
| | | | | | | | | | | | | After the fans have initialized their Functional inventory property, send systemd the READY notification. If the service which runs this application is of type = notify, then systemd will hold off starting any dependent services until this is sent. In our case, we want phosphor-fan-control --control to not be started until this notification is done. Change-Id: Iec87418ce308aa9ca81a47c20039ade7e8fe66c3 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Move Fan objects back to heapMatt Spinler2017-05-121-2/+2
| | | | | | | | Turns out that with the objects on the stack, some of them were corrupt in the callbacks. Change-Id: Ifd4179839d4e05fdb1f05e417093cb14cec3addc Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Use unique_ptr for sd_event object wrapperMatt Spinler2017-05-115-12/+10
| | | | | | | | Convert the sd_event object wrapper from a shared_ptr to a unique_ptr. Requires a new header file. Change-Id: I868a9e88ed93878c2e0bb12e58f8d3a604510da0 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Generate data from yaml during buildMatt Spinler2017-05-113-55/+42
| | | | | | | Run the python script to generate fan_zone_defs.cpp Change-Id: I242aa4246a277509ddbcf1c62fec96782a48b37b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Python script to generate monitor dataMatt Spinler2017-05-111-0/+73
| | | | | | | Generate the data structures from yaml data. Change-Id: I8e21fa099f9365b8c8c7d2227c4debc263601b72 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add inventory update supportMatt Spinler2017-05-112-2/+94
| | | | | | | | | Set a fan's Functional property to false when it has been out of spec for too long. When it is back in spec, set it back to functional. Change-Id: I264129479c58fd296df7c3a1d3d42f5d7aa7b60b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add timer start/stop supportMatt Spinler2017-05-111-1/+43
| | | | | | | | | | In Fan's tachChanged handler, start up the timer for a sensor if it is running too slow. If it is within spec, stop the timer if running and make the sensor functional again if necessary. Change-Id: Ib18de2b69942d334da0cb8cd4cc4de8a2784efab Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Fill in main() functionMatt Spinler2017-05-111-1/+43
| | | | | | | Create the Fan objects, and start the dbus/event loop. Change-Id: I7c6a60bb5d2c20578b529e7e5f3dc13f50e55dd7 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add Timer support to TachSensorMatt Spinler2017-05-114-8/+59
| | | | | | | Add a Timer object to the TachSensor class Change-Id: I419b5712de9e8e94f2a08de84d13170e44c33c7a Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add dbus support to TachSensorMatt Spinler2017-05-115-1/+283
| | | | | | | | | | | | | | | TachSensor will match on properties changed signals for the Value and Target properties. When these occur, it will load in those properties and then tell the Fan class there was a change. Also, TachSensor will read in the Target property during construction so it will have a valid value to check against right away. Change-Id: I2dc2cacf5804826c6b0e0ea91196cbdaa4d5b893 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Fan and TachSensor class introductionMatt Spinler2017-05-115-1/+445
| | | | | | | | | | | | | A Fan object has one or more TachSensor objects. The TachSensor class is used to keep track of the the actual and expected speeds. It only tracks expected speeds if the _hasTarget attribute is true. Future commits will add more functionality. Change-Id: I9bb5fac39f25c5c31c18457ebedf82838fcf6641 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Fan monitor dataMatt Spinler2017-05-114-0/+94
| | | | | | | | | | | This commit contains the data that will be used by the monitor code. The generated.cpp file will later be generated during the build by a python script. Change-Id: I4dc4552ae8e58cd27478416888dd3363e7c2bf3f Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* phosphor-fan-monitor frameworkMatt Spinler2017-05-112-0/+38
This application will monitor the actual speeds of fans (via their sensors) and compare them to their expected speeds. If a fan is too slow for too long, it will have its Functional property in the inventory set to false. If it starts working again, the property will be set back to true. It will use configuration data to say which fans to check and which values to use for various timeout and deviation parameters. Change-Id: Ic61613018a758727835b70f2df0ecd1bf12e8256 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
OpenPOWER on IntegriCloud