"Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes:
> Distros vary the way they enable SysRq by default - mostly they seem
> to enable some mask and then majority of the SysRq functions are
> disabled. For instance, xmon does not even have a mask, and unsless
> SysRq are completely enabled ( == 1), xmon trigger keeps disabled.
>
> Countless times while investigating hangs we needed xmon and it was
> disabled - machine just got hung and while in serial console, we just
> couldn't drop to xmon, forcing to a new attempt to reproduce the issue
> with SysRq fully enabled.
>
> This patch "fixes" this by having xmon enabled in all possible masks
> of SysRq. In other words, xmon trigger will only be disabled if SysRq
> is 0 (completely disabled). So, while debugging a hung, when one tries
> to drop to xmon this patch prevents the frustrating message:
> "This sysrq operation is disabled".
I know it's annoying when you get stuck with a box like this, but I
can't merge this patch.
You're *removing* the system administrators ability to control access to
xmon (other than disabling sysrq entirely). That's a regression.
What we should do is get a bit allocated for xmon, so it can have a
non-zero single-bit enable mask.
cheers
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 4679aeb84767..780d708472a2 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -3514,6 +3514,7 @@ static struct sysrq_key_op sysrq_xmon_op = {
> .handler = sysrq_handle_xmon,
> .help_msg = "xmon(x)",
> .action_msg = "Entering xmon",
> + .enable_mask = 0xFFFF,
> };
>
> static int __init setup_xmon_sysrq(void)
> --
> 2.14.2
