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.
Best Answer
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:
(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:
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):
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