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.

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

show more ...

ensure stop-instructions service stopped during istep

IBM systems utilize istep to boot a system in a more manual "debug
mode". istep does not utilize the host systemd targets to boot the
system, an

ensure stop-instructions service stopped during istep

IBM systems utilize istep to boot a system in a more manual "debug
mode". istep does not utilize the host systemd targets to boot the
system, and instead directly communicates with the host firmware to boot
the system.

This results in the obmc-host-* targets not being run as a part of the
boot, which results in op-stop-instructions@.service.in not getting it's
"Conflicts" operation to run. This means after an istep boot, the
op-stop-instruction@.service has not properly stopped, which results in
it not properly running during the power off of the next boot.

Because op-stop-instruction@.service is now responsible for stopping the
attn handler, this is not a good situation.

istep boots however do still utilize the obmc-chassis-poweron@.target to
power the system on. Add a Conflits for this target to ensure
op-stop-instructions@.service is stopped in all scenarios. Leave the
Conflits with obmc-host-startmin@.target to ensure the service is still
properly stopped on warm reboots.

Tested:
- Performed an istep boot, and verified during the subsequent power off
that op-stop-instructions@0.service was properly run

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

show more ...

Make ATTN service stop a non-fatal event

Return true always for request to stop the ATTN service. This is
needed to pass CI in cases where the ATTN service is not installed.

Tested: With change in

Make ATTN service stop a non-fatal event

Return true always for request to stop the ATTN service. This is
needed to pass CI in cases where the ATTN service is not installed.

Tested: With change in place when op-stop-instructions service is
started verify that journal does not indicate a failure in
op-stop-instructions service specifically in current iteration of
hardware CI.

Signed-off-by: Ben Tyner <ben.tyner@ibm.com>
Change-Id: Id1852082c768dd742afb85098a2120bda1acb41b

show more ...

Stop ATTN service before instruction stop

Ensuring that ATTN service is stopped after PHYP has completed the power
off process. PHYP must be done before starting instruction stop. So that
is a good

Stop ATTN service before instruction stop

Ensuring that ATTN service is stopped after PHYP has completed the power
off process. PHYP must be done before starting instruction stop. So that
is a good target to use.

ATTN service will not be stopped in the MPIPL case since the instruction
stop service is not used. We need to explicitly restart ATTN service in
MPIPL continue so that attention interrupts with no active attention
sources get cleared.

Tested: Verified on graceful shutdown that attention handler service was
stopped after soft-off app had finished (perform graceful shutdown).
Verified that following an MPIPL attention handler would service
attentions (inject error following MPIPL completion).

Change-Id: I52fb75a0bbfa48c714850aa2d3ed9229179cceea
Signed-off-by: Zane Shelley <zshelle@us.ibm.com>
Signed-off-by: Ben Tyner <ben.tyner@ibm.com>

show more ...

remove wants on synch targets in stop-instructions

openbmc/phosphor-state-manager#21 highlights an architecture issue with
OpenBMC's use of synchronization targets. When a service, such as
op-stop-i

remove wants on synch targets in stop-instructions

openbmc/phosphor-state-manager#21 highlights an architecture issue with
OpenBMC's use of synchronization targets. When a service, such as
op-stop-instructions@.service, runs both in a standard power off
target, as well as in other paths (like the host quiesce path), there
is an issue.

The service starts the synchronization targets in the quiesce path and
this causes them to already be running on the power off, resulting in
the synchronization targets not actually coordinating the power off.

The direction this commit takes OpenBMC is that if a service needs to
run outside of the standard power on or off path, then they can not
have a Wants or Requires clause in the service file.

The following commit was done a while back to address this issue:
https://gerrit.openbmc.org/c/openbmc/phosphor-state-manager/+/40026

That is that we ensure the primary power on and off targets start the
synchronization targets so services requiring them can just use a
Before or After clause.

The piece that was never done was to go and fix the services which fell
into this bucket.

Tested:
- Did multiple boots, reboots, and host crash tests and saw no issues

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

show more ...

op-stop-instructions: change service timeout value to 20 sec

Processor level stop instruction api takes close to 1.5 seconds
including thread status updates. Incase of systems with larger
configurat

op-stop-instructions: change service timeout value to 20 sec

Processor level stop instruction api takes close to 1.5 seconds
including thread status updates. Incase of systems with larger
configuration this service fail to complete. changed service
timeout to 20 seconds to support 8 processor configuration system.

Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com>
Change-Id: I36a55f234db7a5f98821cb6362e1e7d95fcf36ef

show more ...

PHAL: Add service dependency to DEVTREE creation

Start the services that require DEVTREE after the
openpower-update-bios-attr-table.service since that's the one that
sets up the DEVTREE symlink. Als

PHAL: Add service dependency to DEVTREE creation

Start the services that require DEVTREE after the
openpower-update-bios-attr-table.service since that's the one that
sets up the DEVTREE symlink. Also update the path to DEVTREE to the one
defined by the meson options.

Tested: Verified phal started after the bios attr service file, powered
on, and issued reboot at power on without any errors. Verified service
files had devtree path of:
Environment="PDBG_DTB=/media/hostfw/running/DEVTREE"

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

show more ...

pdbg api based op-stop-instructions service updates

Replaced pdbg tool based stop all with api based
openpower-proc-control procedure based approach.

Signed-off-by: Jayanth Otha

pdbg api based op-stop-instructions service updates

Replaced pdbg tool based stop all with api based
openpower-proc-control procedure based approach.

Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com>
Change-Id: I4c4f635ec87f128dbcb89e6c78e4f1a0b41a2cd7

show more ...

service-files: move to own sub-directory

Some more service files are on their way for new features so put all of
them in a sub-directory to keep the main one a bit cleaner

Signe

service-files: move to own sub-directory

Some more service files are on their way for new features so put all of
them in a sub-directory to keep the main one a bit cleaner

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

show more ...