== A surprise about Linux serial consoles Here is a surprise I just discovered about magic SysRq and serial consoles: in order to have a serial console respond to magic SysRq, you need something talking to it. If your serial console is _/dev/console_, I believe that this is automatic; however, [[if it is not ManyConsolesOfLinux]] (if you have hooked it up to debug system lockups in X, for example, as a not entirely hypothetical example), you need to run a _getty_ or something on the serial port in order to have the kernel notice magic SysRq sequences. If you don't, what happens is relatively weird. Instead of just ignoring the magic SysRq sequences outright, the kernel seems to buffer them until something opens the serial port, at which point they all suddenly take effect. And if you stop your _getty_ process, things go back to sleep until you restart it. (I tried to follow the code paths through the kernel to figure out what was really going on, but my knowledge of Linux kernel internals is not deep enough to be up to the task.) Unfortunately, all this didn't do me much good; while the serial console did capture a kernel panic, it was the sort where the kernel is in a really bad state and magic SysRq doesn't work afterwards, so I suspect that I have [[reappearing hardware issues FC6EXAOnATIProblems]], hopefully heat and cooling related (they would be cheaper to fix than a broken motherboard).