^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) Linux Magic System Request Key Hacks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Documentation for sysrq.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) What is the magic SysRq key?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) It is a 'magical' key combo you can hit which the kernel will respond to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) regardless of whatever else it is doing, unless it is completely locked up.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) How do I enable the magic SysRq key?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) configuring the kernel. When running a kernel with SysRq compiled in,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) /proc/sys/kernel/sysrq controls the functions allowed to be invoked via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) the SysRq key. The default value in this file is set by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE config symbol, which itself defaults
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) to 1. Here is the list of possible values in /proc/sys/kernel/sysrq:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) - 0 - disable sysrq completely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) - 1 - enable all functions of sysrq
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) - >1 - bitmask of allowed sysrq functions (see below for detailed function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) description)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) 2 = 0x2 - enable control of console logging level
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) 4 = 0x4 - enable control of keyboard (SAK, unraw)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 8 = 0x8 - enable debugging dumps of processes etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 16 = 0x10 - enable sync command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) 32 = 0x20 - enable remount read-only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) 64 = 0x40 - enable signalling of processes (term, kill, oom-kill)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 128 = 0x80 - allow reboot/poweroff
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 256 = 0x100 - allow nicing of all RT tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) You can set the value in the file by the following command::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) echo "number" >/proc/sys/kernel/sysrq
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) The number may be written here either as decimal or as hexadecimal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) with the 0x prefix. CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE must always be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) written in hexadecimal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) Note that the value of ``/proc/sys/kernel/sysrq`` influences only the invocation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) via a keyboard. Invocation of any operation via ``/proc/sysrq-trigger`` is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) always allowed (by a user with admin privileges).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) How do I use the magic SysRq key?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) On x86
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) You press the key combo :kbd:`ALT-SysRq-<command key>`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) Some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) also known as the 'Print Screen' key. Also some keyboards cannot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) handle so many keys being pressed at the same time, so you might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) have better luck with press :kbd:`Alt`, press :kbd:`SysRq`,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) release :kbd:`SysRq`, press :kbd:`<command key>`, release everything.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) On SPARC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) You press :kbd:`ALT-STOP-<command key>`, I believe.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) On the serial console (PC style standard serial ports only)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) You send a ``BREAK``, then within 5 seconds a command key. Sending
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) ``BREAK`` twice is interpreted as a normal BREAK.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) On PowerPC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) :kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) On other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) If you know of the key combos for other architectures, please
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) let me know so I can add them to this section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) On all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) Write a character to /proc/sysrq-trigger. e.g.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) echo t > /proc/sysrq-trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) The :kbd:`<command key>` is case sensitive.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) What are the 'command' keys?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) =========== ===================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Command Function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) =========== ===================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) ``b`` Will immediately reboot the system without syncing or unmounting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) your disks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) ``c`` Will perform a system crash by a NULL pointer dereference.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) A crashdump will be taken if configured.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) ``d`` Shows all locks that are held.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) ``e`` Send a SIGTERM to all processes, except for init.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) ``f`` Will call the oom killer to kill a memory hog process, but do not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) panic if nothing can be killed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) ``g`` Used by kgdb (kernel debugger)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) ``h`` Will display help (actually any other key than those listed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) here will display help. but ``h`` is easy to remember :-)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) ``i`` Send a SIGKILL to all processes, except for init.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) ``j`` Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) ``k`` Secure Access Key (SAK) Kills all programs on the current virtual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) console. NOTE: See important comments below in SAK section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ``l`` Shows a stack backtrace for all active CPUs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) ``m`` Will dump current memory info to your console.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) ``n`` Used to make RT tasks nice-able
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) ``o`` Will shut your system off (if configured and supported).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) ``p`` Will dump the current registers and flags to your console.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) ``q`` Will dump per CPU lists of all armed hrtimers (but NOT regular
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) timer_list timers) and detailed information about all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) clockevent devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) ``r`` Turns off keyboard raw mode and sets it to XLATE.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) ``s`` Will attempt to sync all mounted filesystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) ``t`` Will dump a list of current tasks and their information to your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) console.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) ``u`` Will attempt to remount all mounted filesystems read-only.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) ``v`` Forcefully restores framebuffer console
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) ``v`` Causes ETM buffer dump [ARM-specific]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) ``w`` Dumps tasks that are in uninterruptable (blocked) state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) ``x`` Used by xmon interface on ppc/powerpc platforms.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) Show global PMU Registers on sparc64.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) Dump all TLB entries on MIPS.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) ``y`` Show global CPU Registers [SPARC-64 specific]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) ``z`` Dump the ftrace buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) ``0``-``9`` Sets the console log level, controlling which kernel messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) will be printed to your console. (``0``, for example would make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) it so that only emergency messages like PANICs or OOPSes would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) make it to your console.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) =========== ===================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) Okay, so what can I use them for?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) Well, unraw(r) is very handy when your X server or a svgalib program crashes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) sak(k) (Secure Access Key) is useful when you want to be sure there is no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) trojan program running at console which could grab your password
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) when you would try to login. It will kill all programs on given console,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) thus letting you make sure that the login prompt you see is actually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) the one from init, not some trojan program.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) .. important::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) In its true form it is not a true SAK like the one in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) c2 compliant system, and it should not be mistaken as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) such.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) It seems others find it useful as (System Attention Key) which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) useful when you want to exit a program that will not let you switch consoles.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) (For example, X or a svgalib program.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) ``reboot(b)`` is good when you're unable to shut down, it is an equivalent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) of pressing the "reset" button.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) ``crash(c)`` can be used to manually trigger a crashdump when the system is hung.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) Note that this just triggers a crash if there is no dump mechanism available.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) ``sync(s)`` is handy before yanking removable medium or after using a rescue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) shell that provides no graceful shutdown -- it will ensure your data is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) safely written to the disk. Note that the sync hasn't taken place until you see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) the "OK" and "Done" appear on the screen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) ``umount(u)`` can be used to mark filesystems as properly unmounted. From the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) running system's point of view, they will be remounted read-only. The remount
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) isn't complete until you see the "OK" and "Done" message appear on the screen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) The loglevels ``0``-``9`` are useful when your console is being flooded with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) kernel messages you do not want to see. Selecting ``0`` will prevent all but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) the most urgent kernel messages from reaching your console. (They will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) still be logged if syslogd/klogd are alive, though.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) ``term(e)`` and ``kill(i)`` are useful if you have some sort of runaway process
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) you are unable to kill any other way, especially if it's spawning other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) processes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) "just thaw ``it(j)``" is useful if your system becomes unresponsive due to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) frozen (probably root) filesystem via the FIFREEZE ioctl.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) Sometimes SysRq seems to get 'stuck' after using it, what can I do?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) That happens to me, also. I've found that tapping shift, alt, and control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) on both sides of the keyboard, and hitting an invalid sysrq sequence again
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) will fix the problem. (i.e., something like :kbd:`alt-sysrq-z`). Switching to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) another virtual console (:kbd:`ALT+Fn`) and then back again should also help.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) I hit SysRq, but nothing seems to happen, what's wrong?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) There are some keyboards that produce a different keycode for SysRq than the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) pre-defined value of 99
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) (see ``KEY_SYSRQ`` in ``include/uapi/linux/input-event-codes.h``), or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) which don't have a SysRq key at all. In these cases, run ``showkey -s`` to find
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) an appropriate scancode sequence, and use ``setkeycodes <sequence> 99`` to map
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) this sequence to the usual SysRq code (e.g., ``setkeycodes e05b 99``). It's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) probably best to put this command in a boot script. Oh, and by the way, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) exit ``showkey`` by not typing anything for ten seconds.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) I want to add SysRQ key events to a module, how does it work?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) In order to register a basic function with the table, you must first include
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) the header ``include/linux/sysrq.h``, this will define everything else you need.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) Next, you must create a ``sysrq_key_op`` struct, and populate it with A) the key
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) handler function you will use, B) a help_msg string, that will print when SysRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) prints help, and C) an action_msg string, that will print right before your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) handler is called. Your handler must conform to the prototype in 'sysrq.h'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) After the ``sysrq_key_op`` is created, you can call the kernel function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) ``register_sysrq_key(int key, const struct sysrq_key_op *op_p);`` this will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) register the operation pointed to by ``op_p`` at table key 'key',
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) if that slot in the table is blank. At module unload time, you must call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) the function ``unregister_sysrq_key(int key, const struct sysrq_key_op *op_p)``,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) which will remove the key op pointed to by 'op_p' from the key 'key', if and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) only if it is currently registered in that slot. This is in case the slot has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) been overwritten since you registered it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) The Magic SysRQ system works by registering key operations against a key op
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) lookup table, which is defined in 'drivers/tty/sysrq.c'. This key table has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) a number of operations registered into it at compile time, but is mutable,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) and 2 functions are exported for interface to it::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) register_sysrq_key and unregister_sysrq_key.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) Of course, never ever leave an invalid pointer in the table. I.e., when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) your module that called register_sysrq_key() exits, it must call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) unregister_sysrq_key() to clean up the sysrq key table entry that it used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) Null pointers in the table are always safe. :)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) If for some reason you feel the need to call the handle_sysrq function from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) within a function called by handle_sysrq, you must be aware that you are in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) a lock (you are also in an interrupt handler, which means don't sleep!), so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) you must call ``__handle_sysrq_nolock`` instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) When I hit a SysRq key combination only the header appears on the console?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) Sysrq output is subject to the same console loglevel control as all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) other console output. This means that if the kernel was booted 'quiet'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) as is common on distro kernels the output may not appear on the actual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) console, even though it will appear in the dmesg buffer, and be accessible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) via the dmesg command and to the consumers of ``/proc/kmsg``. As a specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) exception the header line from the sysrq command is passed to all console
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) consumers as if the current loglevel was maximum. If only the header
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) is emitted it is almost certain that the kernel loglevel is too low.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) Should you require the output on the console channel then you will need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) to temporarily up the console loglevel using :kbd:`alt-sysrq-8` or::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) echo 8 > /proc/sysrq-trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) Remember to return the loglevel to normal after triggering the sysrq
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) command you are interested in.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) I have more questions, who can I ask?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) Just ask them on the linux-kernel mailing list:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) linux-kernel@vger.kernel.org
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) Credits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) ~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) - Written by Mydraal <vulpyne@vulpyne.net>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) - Updated by Adam Sulmicki <adam@cfar.umd.edu>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) - Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) - Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com>
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags