Revision Date Author Comments
# 8c90f319 09-May-2023 Andrew Geissler <geissonator@yahoo.com>

systemd: no installation in templated targets

Upstream yocto introduced a change via e510222 (systemd-systemctl:
fix instance template WantedBy symlink construction).

This fixes a bug that we in Op

systemd: no installation in templated targets

Upstream yocto introduced a change via e510222 (systemd-systemctl:
fix instance template WantedBy symlink construction).

This fixes a bug that we in OpenBMC had been taking advantage of in that
we were able to document our templated target dependencies without it
actually doing anything. The real installation of services within
targets occurs in our bitbake recipes due to the complexity of chassis
and host instances on a per machine basis.

Leave the dependency information in the service files but comment them
out. It's useful to be able to look at a service and understand which
targets it's going to be installed into by the bitbake recipes.

In some cases, we had hard coded the target instance, which does install
the service correctly, but only in that one target. All services should
be installed via the bitbake recipe to ensure the service is properly
installed in all instances of the target. Once the bump for this commit
goes into openbmc/openbmc, I will ensure the recipe is updated to
install all services correctly.

Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

show more ...


# dc777fa2 06-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 ...


# d1307294 19-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 ...


# e97fc13a 14-Sep-2021 Shawn McCarney <shawnmm@us.ibm.com>

regulators: Fix race condition in monitor disable

There is a systemd service file that disables regulator monitoring when
the chassis is powered off. This is necessary because we do not

regulators: Fix race condition in monitor disable

There is a systemd service file that disables regulator monitoring when
the chassis is powered off. This is necessary because we do not want to
read sensor values or check for phase faults when the chassis is powered
off. Monitoring needs to stop before the regulators are disabled/turned
off.

The service file currently does not specify a 'Type', which means that
it defaults to Type 'simple'. Service files of this Type are considered
started when they fork the specified executable. That is, systemd does
not wait for the executable to complete.

In this case, we need the executable to complete. The service runs the
regsctl executable, which makes a D-Bus method call to the regulators
application disabling monitoring. We need this D-Bus method to complete
before proceeding with the power off.

Otherwise there is a race condition between the following:
* The timers that initiate sensor and phase fault monitoring could
expire, causing unwanted monitoring to occur during power off.
* The regsctl executable could complete the D-Bus call, stopping
monitoring and the associated timers.

The solution is to set the Type of the service file to 'oneshot'. This
causes systemd to wait until the executable completes.

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

show more ...


# 01bc6120 29-Jan-2020 Matthew Barth <msbarth@us.ibm.com>

regs: Add/install monitor disable service

Create a service file to call a method within the phosphor-regulators
binary to disable monitoring of the regulators. Add this service file to

regs: Add/install monitor disable service

Create a service file to call a method within the phosphor-regulators
binary to disable monitoring of the regulators. Add this service file to
be installed within the systemd services
directory(`/lib/systemd/system/`).

Tested:
Disable of monitoring is called the earliest after a request to
poweroff

Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
Change-Id: Idd8ad73c807faddc90a7d86fd09da0508d5461dd

show more ...