| commit | 1dc6adc90d294b0acd85c5203af266c8e22f9527 | [log] [tgz] |
|---|---|---|
| author | Andrew Jeffery <andrew@aj.id.au> | Thu Jan 13 14:34:37 2022 +1030 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Fri Jan 21 10:14:58 2022 +1030 |
| tree | fe1387244b47840ffd6306b0adf60faf381586f5 | |
| parent | d65368be2872800621eb2528d6ff9494ab2362c3 [diff] |
main: Extract a 'sink' abstraction In the future we'll add a set of sink actions that call through D-Bus to generate a BMC dump and do a graceful reboot rather than crashing the system through /proc/sysrq-trigger. Reorganise the code so the process() function operates on abstract sink types. This way we can encapsulate the D-Bus specifics in a way that doesn't affect the process() implementation. Concretely, there are two actions that can be triggered by the source, 'debug' and 'reboot'. Add the same as callbacks on the sink structure and implement the 'sysrq' behaviours in terms of the new abstraction. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Change-Id: Ic62348365e9d0f13abbdcd81848bc4ca344135ee
debug-trigger listens for an external signal that the BMC is in some way unresponsive. When the signal is received it triggers a crash to collect debug data and reboots the system in the hope that it will recover.
debug-trigger implements a simple protocol over an LPC KCS device as its trigger source.
debug-trigger implements a single action once the trigger event is received, which is to crash the kernel via /proc/sysrq-trigger. For systems with kdump configured this results in collection of system state as context for why the system was externally unresponsive.