On many different machines, when I come across a lockup, I often use Alt+SysRq+REISUB to reboot without too much losses. But I often noticed that although REISU commands work even when I just hold Alt+SysRq and enter them without releasing Alt+SysRq, the last one, B, seems to be very "lazy": I have to repeat it many times, and in fact it doesn't trigger until I do the cycle "press Alt+SysRq, type B, release Alt+SysRq" multiple times (and not always the same number of times).

At first occurrences of this problem I thought it's the kernel which has locked too hard that it doesn't "see" my B command, but when I realized that multiple repetitions of it do allow me to trigger reboot, it now seems that it's something general. Even on a working system (be it Debian, Ubuntu, LFS etc.), I can easily reproduce this. In fact, I can even load the kernel with init=/bin/bash and reproduce this from this bash prompt.

Looking at serial console output, I see all the feedback on REISU, but only one feedback print on multiple B commands — when the kernel finally is convinced to do a reboot.

Why is this? Is it some kernel feature which prevents unintended reset, or maybe it's just a bug (quite strange one)?

Note that I'm using plain keyboard with no Fn or multimedia keys, so this question isn't a duplicate of this one.

1 Answer 1


The problem is not in software, it's in hardware. Keyboard keys are not independent: there're about 100 keys, but only about 26 wires going into keyboard's internal controller:

enter image description here

(Image from dreamstime.com)

This means that not all keys can be detected when simultaneously pressed. Because RAlt is much closer to SysRq than LAlt, I always use it to free one hand for entering chars. But it appears that on most (all?) PC keyboards RAlt+SysRq+B doesn't send scancode of B!*

Why do I then finally get the reboot? It's simple: when I'm very annoyed that I can't reboot the machine with this semi-working command, I press the combo many times without too much attention, sometimes mixing presses and releases of keys — and it appears that SysRq isn't a normal modifier for linux, like e.g. Alt is: the magic-SysRq mode is active even after I release SysRq but still hold Alt. Then the sequence which appears to work is:

  • Press RAlt
  • Press SysRq
  • Release SysRq
  • Press B
  • See reboot

For LAlt things appear much simpler: the keyboard is able to detect B when LAlt+SysRq is held, so there's no problem, but I never noticed it before because I always used RAlt.

Funnily, it appears that this issue is long known, and the workaround is that same which I've discovered empirically. From kernel source tree, Documentation/sysrq.txt (emphasis mine):

On x86 - You press the key combo 'ALT-SysRq-<command key>'. Note - Some keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is also known as the 'Print Screen' key. Also some keyboards cannot handle so many keys being pressed at the same time, so you might have better luck with "press Alt", "press SysRq", "release SysRq", "press <command key>", release everything.

So, looks like this trick is an official recommendation, not an unreliable side effect of implementation.

*I've actually checked this with a simple DOS program which reports every scan code the i8042 gives on each IRQ1

  • 1
    Yep! There are "gaming" or "professional" keyboards that do register all keys separately. Search for "n-key rollover", or NKRO. (Das Keyboard is one example. I have no affiliation with them except I love mine.)
    – mattdm
    Commented Jul 12, 2014 at 7:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .