SYNOPSIS

sr x

DESCRIPTION

The sr command invokes the existing sysrq handler code in the kernel. This command takes a single character which is passed to sysrq processing, as if you had entered the sysrq key sequence followed by that character.

Caveats:

kdb will always call the sysrq code but sysrq may be disabled. If you expect to use sysrq functions during debugging then

echo "1" > /proc/sys/kernel/sysrq

before starting the debug session. Alternatively issue

mm4 sysrq_enabled 1

during debugging.

The sysrq code prints a heading using console loglevel 7 then reverts to the original loglevel for the rest of the sysrq processing. If the rest of the sysrq output is printed at a level below your current loglevel then you will not see the output on the kdb console, the output will only appear in the printk buffer. It is the user's responsibility to set the loglevel correctly if they want to see the sysrq output on the console. Issue

sr 7

before any other sr commands if you want to see the output on the console. You may even have to adjust the default message loglevel in order to see any output from sr. See Documentation/sysctl/kernel.txt for details on setting console loglevels via /proc. You can also adjust the loglevel variables via kdb mm; on older kernels there are variables such as default_message_level, on newer kernels all the loglevel variables are in array console_printk, see kernel/printk.c for your kernel.

Operations that require interrupt driven I/O can be invoked from kdb sr, but they will not do anything until you type 'go' to exit from kdb (interrupts are disabled while in kdb). There is no guarantee that these operations will work, if the machine entered kdb because of an error then interrupt driven I/O may already be dead. Do not assume that sr s does anything useful.

The sysrq handler uses locks and calls printk which also uses locks. If the sysrq handler or any of the sysrq functions have to wait for a lock then they will never return and kdb will appear to hang. Invoking sysrq code from kdb is inherently unsafe.