Bug 152127 - sysrq does not work on serial console
sysrq does not work on serial console
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Maly
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-24 22:11 EST by Ken Sugawara
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-19 16:03:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ken Sugawara 2005-03-24 22:11:14 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
Comment 1 Ken Sugawara 2005-03-24 22:14:04 EST
Forgot to mention that the kernel is built with options CONFIG_SERIAL_CONSOLE
and CONFIG_MAGIC_SYSRQ both set.
Comment 2 Jason Baron 2005-04-19 13:40:28 EDT
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.
Comment 3 Stephen Tweedie 2005-04-19 18:14:42 EDT
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.
Comment 4 David Woodhouse 2005-05-09 06:06:57 EDT
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.
Comment 5 Jason Baron 2005-05-11 14:20:21 EDT
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

Note You need to log in before you can comment on or make changes to this bug.