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 [root@romrom root]# Version-Release number of selected component (if applicable): kernel-2.4.21-20.EL How reproducible: Always 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 Additional info: 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 echoctl echoke
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 here. thanks.
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? Try this: 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