Red Hat Bugzilla – Bug 152127
sysrq does not work on serial console
Last modified: 2007-11-30 17:07:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Description of problem:
I've set up serial console by adding the following:
1. "serial --unit=1 --speed=9600 --word=8 --parity=no --stop=1" and "terminal --timeout=10 serial console" lines to /boot/grub/grub.conf
2. "console=tty0 console=ttyS1,9600n8" to grub.conf's kernel bootstrap option
3. "ttyS1" to /etc/securetty
4. mingetty line for "ttyS1" to /etc/inittab
and after reboot, serial console works as expected. I can login from serial console, view kernel messages on it, etc.
However, I cannot trigger Magic SysRq by sending break signal to the serial port. It seems ignored. Below is a session log. At first line, I sent a break then pressed 'h' (well within 5 seconds). Instead of showing sysrq help message, it showed just 'h' (then I typed enter so bash is complaining about h being non-existent command). Next I echoed 'h' to /proc/sysrq-trigger and it works as it should. This should demonstrate that I have enabled sysrq.
[root@romrom root]# h
-bash: h: command not found
[root@romrom root]# echo h >/proc/sysrq-trigger
SysRq : HELP : loglevel0-8 reBoot Crash tErm kIll saK showMem showPc unRaw Sync
showTasks Unmount shoWcpus
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up serial console
2. Connect a terminal or a PC running terminal emulator to the serial port
3. Send break and sysrq command
Actual Results: No effect.
Expected Results: SysRq handled
This bug itself does not cause crashes, loss of data or severe memory leak, but is interfering with our customer's attempt to collect kernel internal information for debugging the kernel hang problem they are experiencing (their server is an IBM BladeCenter server with shared USB keyboard and mouse that come and go as operator switches blade's console which makes it almost impossible to do SysRq on the non-serial console), so its priority should be considered "high".
Just in case, I've attached stty output for the serial console device below:
[root@romrom root]# stty -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^X; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo -echoe -echok -echonl -noflsh -xcase -tostop echoprt
Forgot to mention that the kernel is built with options CONFIG_SERIAL_CONSOLE
and CONFIG_MAGIC_SYSRQ both set.
This seems to work for me. To be clear, my setup was a a rhel2.1 box sending a
break followed by a sysrq key to a rhel3 system. This seems to work fine. Are
you sure that you are sending a break over the serial line?
If so, the next place to look seems to be the specific serial driver in use here
since the handling of the sysrq key is in generic code. That is, perhaps the
serial driver is properly passing the break key up to the generic sysrq handling
layer. A 'dmesg' output would be helpful in determining the specific h/w in use
Also, irrespective of whether there's a bug in the break handling, it would be
useful for the user to be aware of an alternative way to do sysrq over serial
console. If you echo an ascii number to /proc/sys/kernel/sercons_esc, then that
key becomes a sysrq escape: when pressed, the next key on the serial console is
treated as a sysrq command. (Eg. "echo 16 > /proc/sys/kernel/sercons_esc", then
use ctrl-P as the sysrq escape key.)
Note that both sysrq escapes and break require (a) that the serial line is
actually configured as a kernel console, not just as a serial terminal (ie. you
need "console=ttyS..." on the kernel command line); and (b) the sysrq character
must arrive within 5 seconds of the break or escape character.
The four steps you describe for enabling serial console don't seem to have
included the step of actually enabling SysRq. Does it even work from the keyboard?
echo 1 > /proc/sys/kernel/sysrq
If that works, edit /etc/sysctl.conf accordingly.
good point. The fact that echo h > /proc/sysrq-trigger showed the helped doesn't
imply that /proc/sys/kernel/sysrq was set to 1. The /proc/sysrq-trigger is
always 'live' independent of the value of /proc/sys/kernel/sysrq