History log of /openbmc/phosphor-power/ (Results 176 – 200 of 840)
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
056bc19506-Jun-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Improve power supply error usage

Improve interaction with power supply application by adding a five
second wait after power good failure to allow time for power supply
failure analysis and add

pseq: Improve power supply error usage

Improve interaction with power supply application by adding a five
second wait after power good failure to allow time for power supply
failure analysis and add use of the passed power supply error if no
voltage fail is found but the power supply error is.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: I63eab737d0fa785130604025ea7bd048780fbb86

show more ...

213ffe9903-Jun-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Create dump on runtime pgood failure

Currently no dump is created when a power good failure occurs at
runtime. Add the call to create a dump.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
C

pseq: Create dump on runtime pgood failure

Currently no dump is created when a power good failure occurs at
runtime. Add the call to create a dump.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: I1effbf13f0b2fd234deea96171efa289f9fa2380

show more ...

ae35ac5d23-May-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Disable INPUT_HISTORY for 1400W IBM PSU

If the device driver is ibm-cpffps, read the MFR_POUT_MAX value
(max_power_out). Only enable INPUT_HISTORY data collection if it is not
the 1400W IBM

psu-ng: Disable INPUT_HISTORY for 1400W IBM PSU

If the device driver is ibm-cpffps, read the MFR_POUT_MAX value
(max_power_out). Only enable INPUT_HISTORY data collection if it is not
the 1400W IBM power supply (MSB/LSB results in 30725 for 1400). The
1400W IBM power supply appears to cause problems on the bus when
an INPUT_HISTORY PMBus command read occurs.

Tested:
Simulated Rainier 2S4U
Fake 2nd and 3rd PSUs to return 1400W value
Verify 1st and 4th collecting INPUT_HISTORY
Verify 2nd and 3rd PSUs not getting INPUT_HISTORY collected
-----
Verify real Rainier 2S4U with 1600W working as expected.

Change-Id: Ia37cea9b0273ac5926e4bc581a2ea8a4079afa23
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

c9e840e410-May-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Lower input history sync delay to 5ms

The delay for the sync GPIO was set to 1100ms due to a PSU firmware bug.
This can be lowered back down to 5ms with the updated PSU firmware for
the 1600

psu-ng: Lower input history sync delay to 5ms

The delay for the sync GPIO was set to 1100ms due to a PSU firmware bug.
This can be lowered back down to 5ms with the updated PSU firmware for
the 1600W power supplies.

Change-Id: I1be327864ce9f37b3604d5e96b25cabe3d170551
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

dc777fa206-May-2022 Shawn McCarney <shawnmm@us.ibm.com>

regulators: Host reboot should not redo operations

While powering on the host, a "warm reboot" of the host may occur one or
more times. For example, the host boot process may update hardware in a
w

regulators: Host reboot should not redo operations

While powering on the host, a "warm reboot" of the host may occur one or
more times. For example, the host boot process may update hardware in a
way that requires a host reboot.

During a "warm reboot" of the host, power to the chassis remains on. As
a result, the following regulator operations should *not* be performed:
* Configuring the regulators again.
* Disabling and then re-enabling regulator monitoring for sensors and
redundant phase faults.

Modify several regulator systemd service files so that those regulator
operations are not performed during a "warm reboot" of the host.

Test Plan:
* https://gist.github.com/smccarney/c2eea054b7439b84b55f4fb89f474413

Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
Change-Id: I5e4c97168f0f7cdd5d7d6bfed227c5769a86d5a8

show more ...

9666ddf627-Apr-2022 Brandon Wyman <bjwyman@gmail.com>

Do not run validation if input/UV fault

If any power supply has an input or VIN_UV fault, do not run the
configuration validation.

Two reasons to avoid running the configuration validation when an

Do not run validation if input/UV fault

If any power supply has an input or VIN_UV fault, do not run the
configuration validation.

Two reasons to avoid running the configuration validation when an input
or VIN_UV fault is present:
1) Avoid unnecessarily logging additional errors.
- We know the voltage is wrong, it will log an error.
2) Avoid logging the configuration invalid error that calls out the
power supply.
- That error would unnecessarily turn on the power supply fault LED.

Tested:
Rainier 2S4U. System power off.
Remove power from powersupply2 and powersupply3.
Power system on.
Without changes:
Two 110015F0 PELs.
One 110015F7 PEL.
SAI LED on.
powersupply2 Health critical, LED on.
powersupply3 Health critical, LED off.
With changes:
Two 110015F0 PELs.
SAI LED on.
powersupply2 Health critical, LED off.
powersupply3 Health critical, LED off.
Resolve input power issue.
Without Changes:
powersupply2 Health critical, LED on.
powersupply3 Health Okay.
With Changes:
powersupply2 Health Okay.
powersupply3 Health Okay.
Attempt resolve input power with wrong voltage:
With Changes:
powersupply0 called out in 110015F7. (wrong voltage)

Change-Id: Ie1628b0d9cf4dc25dc7bd2d4bc3f79779c54de97
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

ba6d960402-May-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: faultLogged to false in clearFaultFlags

Allows for detecting and logging error for new faults.

Tested:
Rainier 2S4U.
Power on.
Remove input power from powersupply0.
110015F0

psu-ng: faultLogged to false in clearFaultFlags

Allows for detecting and logging error for new faults.

Tested:
Rainier 2S4U.
Power on.
Remove input power from powersupply0.
110015F0 logged.
Apply power to powersupply0.
Delete 110015F0.
Turn off SAI LED.
Remove input power from powersupply0.
Verify another 110015F0 logged.
Apply power to powersuply0.
Delete 110015F0.
Turn off SAI LED.

Change-Id: I7a8995b4185f5e1eeeecf373f6e68d2bfe3dc170
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

286bc70002-May-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Add digital monitor rails to voltage fault

In order to provide better isolation prioritization and increase failure
data captured, add the digital monitor (dmon) rails to voltage fault
monitor

pseq: Add digital monitor rails to voltage fault

In order to provide better isolation prioritization and increase failure
data captured, add the digital monitor (dmon) rails to voltage fault
monitoring.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: I82dcee920044c083dd8c1a7c8fa24b6455143582

show more ...

594fd72f02-May-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Correct Everest system rail ordering

Everest system does not order rails in analog monitor (amon) pin order
as previous systems did and as initially assumed. Correct ordering per
additional cl

pseq: Correct Everest system rail ordering

Everest system does not order rails in analog monitor (amon) pin order
as previous systems did and as initially assumed. Correct ordering per
additional clarification from engineering.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: I772457cfca0d50f3567952128fa2742601a41f8b

show more ...

49b8ec4920-Apr-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Add syncHistory for power state on

When the power state changes to on, we should synchronize the power
supply input history data.

Change-Id: I2656b371583583b45c9f511c747404b57d1ec7eb
Signed

psu-ng: Add syncHistory for power state on

When the power state changes to on, we should synchronize the power
supply input history data.

Change-Id: I2656b371583583b45c9f511c747404b57d1ec7eb
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

18a24d9219-Apr-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: INPUT_HISTORY syncHistory

Add in the function that syncs the power supply input history data
between all the installed power supplies.

Use the GPIO line name instead of gpiochip and number.

psu-ng: INPUT_HISTORY syncHistory

Add in the function that syncs the power supply input history data
between all the installed power supplies.

Use the GPIO line name instead of gpiochip and number. Use libgpiod via
helper utility. Create a toggleLowHigh() to use for synchronizing the
input history.

Add in indicator and helper functions to indicate a syncHistory is
needed if a power supply goes from missing to present.

Trace when syncHistory is called. This should be infrequent enough that
I do not think it would be a problem.

Initial testing on Rainier 2S2U did not need a lengthy delay between
lowering and raising the power-ffs-sync-history GPIO, but testing on
Rainier 2S4u required a longer delay.

Depends-On: Ib1ac2456f7f715360d089dfa4b6b379b516439ab

Change-Id: I022806155139d70fb4a42cc27eb9f279f6a3aedc
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

c332442424-Mar-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Power supply class updates for input history

Update the meson files to include the record_manager with the
phosphor-psu-monitor application.

Since we do not want to blindly enable input his

psu-ng: Power supply class updates for input history

Update the meson files to include the record_manager with the
phosphor-psu-monitor application.

Since we do not want to blindly enable input history for all power
supplies, base the enablement of the feature off of the driver name.
Change the PowerSupply class to require the driver name be passed in,
and pass that down via the PSUManager during the configuration
determination.

Add a server manager to the PSUManager to handle the INPUT HISTORY data
that will be under /org/open_power/sensors.

The INPUT_HISTORY command is handled via a sysfs file in binary format,
so add in a readBinary() base function to allow for mock testing.

Change-Id: Iea163892d5482e6f2dacacfbfa746f605af52ed5
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

00d45a5b24-Mar-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Symlink to input history files

Plan to re-use input history related files from Witherspoon development.

Change-Id: I880925c42f5149ae559479bc67756cb78f63a4d4
Signed-off-by: Brandon Wyman <bj

psu-ng: Symlink to input history files

Plan to re-use input history related files from Witherspoon development.

Change-Id: I880925c42f5149ae559479bc67756cb78f63a4d4
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

d130729419-Apr-2022 Zev Weiss <zev@bewilderbeest.net>

regulators: Add phosphor-regulators service dependencies

'regsctl' can't do anything useful until phosphor-regulators is running,
so add systemd unit dependencies to ensure it's started before
regul

regulators: Add phosphor-regulators service dependencies

'regsctl' can't do anything useful until phosphor-regulators is running,
so add systemd unit dependencies to ensure it's started before
regulators-config and regulators-monitor-{enable,disable}.

While we're at it, change phosphor-regulators.service to be of type dbus
so we get a more meaningful check that it's really up and running, and
tweak the instantiation of ManagerObject so that it emits the necessary
signals.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I724e4f335c4347ad6789e2d68cfb58c6387e6073

show more ...

2a05492213-Apr-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Add exists call before reading status vout

The UCD device can support rails which are not configured as voltage
rails and therefore do not have a corresponding status vout sysfs file.
Add an e

pseq: Add exists call before reading status vout

The UCD device can support rails which are not configured as voltage
rails and therefore do not have a corresponding status vout sysfs file.
Add an exists check before reading status vout to support.

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: I9855f777768397fb4582b98ef776173fcb57e51d

show more ...

e367ded812-Apr-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Remove system from inventory mapper-wait

Update the service file for phosphor-psu-monitor to just wait for the
inventory service, not the /system inventory object specifically.
Waiting for t

psu-ng: Remove system from inventory mapper-wait

Update the service file for phosphor-psu-monitor to just wait for the
inventory service, not the /system inventory object specifically.
Waiting for the /system inventory object is unnecessary and can cause
delays in reaching BMC_READY state.

Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Change-Id: I5e1f1f271d0d3389b3a19a946e5360ad54de057c

show more ...

7fce37bc11-Apr-2022 Jim Wright <jlwright@us.ibm.com>

pseq: Cleanup Everest config file pin entries

In order to prevent incorrect isolation, remove from the Everest config
file the pins which do not factor into the overall chassis power good.

This com

pseq: Cleanup Everest config file pin entries

In order to prevent incorrect isolation, remove from the Everest config
file the pins which do not factor into the overall chassis power good.

This commit is the Everest version of
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-power/+/51249

Signed-off-by: Jim Wright <jlwright@us.ibm.com>
Change-Id: Id3f818cadf09205a3d07a0f61fd1944ff835d795

show more ...

3fa31a7c05-Apr-2022 Patrick Williams <patrick@stwcx.xyz>

sdbusplus: object: don't use 'bool' argument constructor

`sdbusplus::server::object_t` has long had an enum-based parameter for
signal action, but maintained a backwards compatible boolean mapping.

sdbusplus: object: don't use 'bool' argument constructor

`sdbusplus::server::object_t` has long had an enum-based parameter for
signal action, but maintained a backwards compatible boolean mapping.
It is time to remove this boolean to make it more observable which
actions are being used in applications. Map all `true` occurrences to
`action::defer_emit`.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ied6d1b6116b07a8f73b398a098298f4990b24818

show more ...

b23e443301-Apr-2022 Adriana Kobylak <anoo@us.ibm.com>

psu-ng: Skip power supply validation if none are present

If no power supplies are present, it means the D-Bus objects have not
been created yet, so skip the power supply validation (the validation
m

psu-ng: Skip power supply validation if none are present

If no power supplies are present, it means the D-Bus objects have not
been created yet, so skip the power supply validation (the validation
may had been requested if the BMC rebooted while the host is on, so when
the psu monitor starts up, the power state changes to On and the
validation is requested).
The validation will be requested again when the power supply D-Bus
objects appear on D-Bus via the interfaces added callback.

Tested: Rebooted the BMC at host runtime and verified no errors were
created.

Change-Id: Ifc59d1add04163afb46a589c0b8387bb3e8636cf
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

fa2734d630-Mar-2022 Shawn McCarney <shawnmm@us.ibm.com>

regulators: Retry failed sensor monitoring

If a failure occurs while trying to read voltage regulator sensors,
retry the operation 5 times before logging an error.

This provides "de-glitching" to i

regulators: Retry failed sensor monitoring

If a failure occurs while trying to read voltage regulator sensors,
retry the operation 5 times before logging an error.

This provides "de-glitching" to ignore transient hardware problems.

Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
Change-Id: I310c15eb0f0d36d938057d6280a12b5aef854d20

show more ...

e5b1e08702-Mar-2022 Adriana Kobylak <anoo@us.ibm.com>

psu-ng: Set the PowerSystemInputs status on Brownout condition

When a brownout condition is detected, set the PowerSystemInputs status
property to Fault to avoid an autorestart, reference design doc

psu-ng: Set the PowerSystemInputs status on Brownout condition

When a brownout condition is detected, set the PowerSystemInputs status
property to Fault to avoid an autorestart, reference design doc:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/48015

Add a Before=xyz.openbmc_project.State.Chassis.service to the psu
monitor service file since the chassis service is the one that will be
reading the property.

Add additional data to the Blackout error log.

Tested: On simulation:

1. Clear brownout at runtime:
- At power on, inject a power fault to all PSUs to trigger a brownout
and verify the CurrentPowerStatus is set to Fault:

Mar 20 19:49:14 p10bmc phosphor-log-manager[318]: Created PEL 0x5000000d
(BMC ID 13) with SRC 110000AC
Mar 20 19:49:14 p10bmc phosphor-power-control[307]:
callbackSetPowerSupplyError:
xyz.openbmc_project.State.Shutdown.Power.Error.Blackout

‣ Type=signal Endian=l Flags=1 Version=1 Cookie=94 Timestamp="Sun
2022-03-20 19:49:14.241856 UTC"
Sender=:1.1296
Path=/xyz/openbmc_project/power/power_supplies/chassis0/psus
Interface=org.freedesktop.DBus.Properties Member=PropertiesChanged
...
STRING
"xyz.openbmc_project.State.Decorator.PowerSystemInputs";
...
STRING
"xyz.openbmc_project.State.Decorator.PowerSystemInputs.Status.Fault";

- Additional data on the error log:

"User Data 1": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "0x2000",
"NOT_PRESENT_COUNT": "2",
"VIN_FAULT_COUNT": "2",
"_PID": "10244"
}

- Clear the brownout condition and verify the status is set to Good.

Change-Id: I29695b641fb81515680a478e872bac29a6de560a
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

c9b0573619-Mar-2022 Adriana Kobylak <anoo@us.ibm.com>

psu-ng: Implement the PowerSystemInputs interface

Implement the PowerSystemInputs interface which contains the status of
the power inputs to the chassis. The psu monitor app will use the status
prop

psu-ng: Implement the PowerSystemInputs interface

Implement the PowerSystemInputs interface which contains the status of
the power inputs to the chassis. The psu monitor app will use the status
property to communicate if a brownout condition exists.
Implement this interface under a /chassis0 path to specify it applies to
the current chassis. This can later be enhanced to support a
multi-chassis configuration.

Tested: The status property exists and it's set to default value Good:
root@p10bmc:~# busctl get-property xyz.openbmc_project.Power.PSUMonitor\
/xyz/openbmc_project/power/power_supplies/chassis0/psus\
xyz.openbmc_project.State.Decorator.PowerSystemInputs Status
s "xyz.openbmc_project.State.Decorator.PowerSystemInputs.Status.Good"

Change-Id: I7cf4d13e632841e0b19b52af0d9eac886eb161ce
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

d97aa51624-Mar-2022 Shawn McCarney <shawnmm@us.ibm.com>

regulators: Add rules and devices to Rainier JSON

Add rules and devices to the Rainier JSON voltage regulator
configuration file.

The JSON rule objects define sequences of actions to configure and

regulators: Add rules and devices to Rainier JSON

Add rules and devices to the Rainier JSON voltage regulator
configuration file.

The JSON rule objects define sequences of actions to configure and read
sensors from Rainier voltage regulators.

The JSON device objects define the regulator devices and what rules
should be run to configure and monitor them.

Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
Change-Id: I07210080e67131c157806235baf7be4b7c33f9fd

show more ...

33d492f423-Mar-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Do not add trailing \0 to VINI SN

The SerialNumber property in the asset decorator properties has the
correct length, but for some reason a null (\0) was added to the end of
the value we sen

psu-ng: Do not add trailing \0 to VINI SN

The SerialNumber property in the asset decorator properties has the
correct length, but for some reason a null (\0) was added to the end of
the value we send out to the VINI SN property. Doing this results in an
incorrect VPD data length.

Tested:
Built fully p10bmc image, flashed to Rainier 2S2U.
Used busctl introspect to examine powersupply properties.
Powered on system
Used PHYP macro to verifyvpd

Change-Id: Id82014c656161bb5e59b2216d7da80c09c3c7f29
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

90d529af22-Mar-2022 Brandon Wyman <bjwyman@gmail.com>

psu-ng: Need driver to bind before updateInventory

If the power supply is present, we need to bind the device driver before
we attempt to read the VPD and other properties from it.

If we are bindin

psu-ng: Need driver to bind before updateInventory

If the power supply is present, we need to bind the device driver before
we attempt to read the VPD and other properties from it.

If we are binding the device driver, we need to ensure we find or update
the directory/path we are using for sysfs files we will read.

Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Change-Id: I2a0b2b3b76c77600ee34c847b62daf4eff40f39a

show more ...

12345678910>>...34