Adding ctrl-o sysrq hack support to 8250 driver
RFC PATCH 1/1 Adding ctrl-o sysrq hack support to 8250 driver
The following patch will allow a user to use sysrq keys over a serial console using the ctrl-o key sequence. This is similar to functionality provided by the hvc console drivers on PPC boxes.
drivers/serial/8250.c +17 -0
@@ -1084,6 +1084,23 @@ receive_chars(struct uart_8250_port *up,*/ } ch =serial_inp (up,UART_RX ); + +#if defined(CONFIG_MAGIC_SYSRQ ) && defined(CONFIG_SERIAL_CORE_CONSOLE ) +/* Handle the SysRq ^O Hack */ +if (ch =='\x0f' ) { + up->port.sysrq = jiffies +HZ *5 ; + goto ignore_char; + } +if (up->port.sysrq) { +int swallow; +spin_unlock (&up->port.lock); + swallow =uart_handle_sysrq_char (&up->port, ch, regs); +spin_lock (&up->port.lock); +if (swallow) + goto ignore_char; + } +#endif /* CONFIG_MAGIC_SYSRQ && CONFIG_SERIAL_CORE_CONSOLE */ + flag =TTY_NORMAL ; up->port.icount.rx++;
Quoted 3 lines · Sachin Sant
The following patch will allow a user to use sysrq keys over a serial console using the ctrl-o key sequence. This is similar to functionality provided by the hvc console drivers on PPC boxes.
is sending a BRK over serial not enough? (the existing method) minicom for sure can send that.. I'm sure all other terminal emulator apps can as well.
Quoted 3 lines · Sachin Sant
The following patch will allow a user to use sysrq keys over a serial console using the ctrl-o key sequence. This is similar to functionality provided by the hvc console drivers on PPC boxes.
Several problems:
1. ^O is normally the "flush" control code, for discarding unsent output.
2. ^O might be inadvertantly received due to a connected PC trying to auto-detect connected devices.
3. see review below.
drivers/serial/8250.c receive_chars(struct uart_8250_port *up, · line 1091
Quoted 12 lines
diff -Naurp linux-2.6.14.3/drivers/serial/8250.c linux-2.6.14.3-new/drivers/serial/8250.c
drivers/serial/8250.c +5
-0@@ -1084,6 +1084,23 @@ receive_chars(struct uart_8250_port *up,*/ } ch =serial_inp (up,UART_RX ); + +#if defined(CONFIG_MAGIC_SYSRQ ) && defined(CONFIG_SERIAL_CORE_CONSOLE ) +/* Handle the SysRq ^O Hack */ +if (ch =='\x0f' ) { + up->port.sysrq = jiffies +HZ *5 ;
Why are you doing this and not using uart_handle_break()?
Do you realise that this enables sysrq support for _any_ 8250 serial port, be it console or not?
drivers/serial/8250.c receive_chars(struct uart_8250_port *up, · line 1098
Quoted 7 lines
drivers/serial/8250.c +7
-0+ goto ignore_char; + } +if (up->port.sysrq) { +int swallow; +spin_unlock (&up->port.lock); + swallow =uart_handle_sysrq_char (&up->port, ch, regs); +spin_lock (&up->port.lock);
We don't drop the lock when calling uart_handle_sysrq_char() further down in this function. Why is this needed? Also, why is this needed to be duplicated?
drivers/serial/8250.c receive_chars(struct uart_8250_port *up, · line 1106
Quoted 8 lines
drivers/serial/8250.c +5
-0+if (swallow) + goto ignore_char; + } +#endif /* CONFIG_MAGIC_SYSRQ && CONFIG_SERIAL_CORE_CONSOLE */ + flag =TTY_NORMAL ; up->port.icount.rx++;
Sorry, NACK.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 5 lines
Why are you doing this and not using
uart_handle_break()?Do you realise that this enables sysrq support for _any_ 8250 serial port, be it console or not?
At present we have ctrl-break that works over a serial connection. But there are few instances where the above does not works. Consider the following senarios
p615, power4, no-hmc configuration.
I attached an IBM 3153 (a "real" tty) to the serial port.I then observed
that neither ctrl-o or the tty's ctrl-SysRq_key worked. (but ctrl-o did still work with the patched kernel, of course). However, the ctrl-Break_key does work on the native tty, taking the place of the ctrl-o on vterms.So in summary, ctrl-Break works. I then re-attached the cu cable (both are defined alike as ttyS0 and give login's) and re-verified that ctrl-Break stopped working.
In the future, if this configuration is found hung, then (provided sysrq was enabled), attach a physical tty and use ctrl-Break to debug.
2nd configuration: p630, hmc-attached, booted in "full-system partition" mode.Everything in the first configuration applied here too.There is only a slight diff in the way the console works.Since the hmc is attached, the "vterm" on the hmc will be the console.However, when it is booted in "full-system partition" mode, the OS sees that console as ttyS0 - just like a non-hmc attached connection.Unfortunately, neither the ctrl-o nor the ctrl-Break works on this either (just like the cu session above).The only way to get ctrl-Break to work is to "close the terminal" operation on the hmc, and then attach and turn on a real tty onto the lowest serial port (not the "HMC" port) on the p630. You can't have both running at the same time, because they both configure as ttyS0. Then with the real tty attached, you can use ctrl-Break to debug.
So the general idea behind this patch was to make the behaviour of invoking sysrq key more consistent over virtual and real consoles. It's not a must but would be nice to have this functionality.
Quoted 5 lines
We don't drop the lock when calling
uart_handle_sysrq_char()further down in this function. Why is this needed? Also, why is this needed to be duplicated?
You are correct. This is not needed. I have removed this piece of code.
How about the following patch.
drivers/serial/8250.c +9 -0
@@ -1084,6 +1084,15 @@ receive_chars(struct uart_8250_port *up,*/ } ch =serial_inp (up,UART_RX ); + +#if defined(CONFIG_MAGIC_SYSRQ ) && defined(CONFIG_SERIAL_CORE_CONSOLE ) +/* Handle the SysRq ^O Hack */ +if (ch =='\x0f' ) { + up->port.sysrq = jiffies +HZ *5 ; + goto ignore_char; + } +#endif /* CONFIG_MAGIC_SYSRQ && CONFIG_SERIAL_CORE_CONSOLE */ + flag =TTY_NORMAL ; up->port.icount.rx++;
Quoted 9 lines · Sachin Sant
Quoted 4 lines
Why are you doing this and not using
uart_handle_break()?Do you realise that this enables sysrq support for _any_ 8250 serial port, be it console or not?
At present we have ctrl-break that works over a serial connection. But there are few instances where the above does not works. Consider the following senarios
Quoted 7 lines
p615, power4, no-hmc configuration.
I attached an IBM 3153 (a "real" tty) to the serial port.I then observed that neither ctrl-o or the tty's ctrl-SysRq_key worked. (but ctrl-o did still work with the patched kernel, of course). However, the ctrl-Break_key does work on the native tty, taking the place of the ctrl-o on vterms.
Frown. Sorry, I'm not sure what "p615", "power4" and "no-hmc" is. I also don't know what an IBM 3153 is.
However, you seem to be suggesting that a terminal application somehow forwards the ctrl-sysrq (and it's actually alt-sysrq). Maybe it does, maybe it doesn't. Probably depends on the terminal application itself.
Eg, with minicom, you need to ask minicom to create the serial break event itself, normally by (assuming default configuration) <ctrl-a> <f>.
Quoted 9 lines
So in summary, ctrl-Break works. I then re-attached the cu cable (both are defined alike as ttyS0 and give login's) and re-verified that ctrl-Break stopped working.
In the future, if this configuration is found hung, then (provided sysrq was enabled), attach a physical tty and use ctrl-Break to debug.
2nd configuration: p630, hmc-attached, booted in "full-system partition" mode.Everything in the first configuration applied here too.
At around this point, I'm starting to loose track of this email - please can you format the message better, eg use at least one space (preferably two) after a full stop and separate up what you want to say into easy to read paragraphs.
Quoted 12 lines
There is
only a slight diff in the way the console works.Since the hmc is attached, the "vterm" on the hmc will be the console.However, when it is booted in "full-system partition" mode, the OS sees that console as ttyS0 - just like a non-hmc attached connection.Unfortunately, neither the ctrl-o nor the ctrl-Break works on this either (just like the cu session above).The only way to get ctrl-Break to work is to "close the terminal" operation on the hmc, and then attach and turn on a real tty onto the lowest serial port (not the "HMC" port) on the p630. You can't have both running at the same time, because they both configure as ttyS0. Then with the real tty attached, you can use ctrl-Break to debug.
Quoted 3 lines
So the general idea behind this patch was to make the behaviour of invoking sysrq key more consistent over virtual and real consoles. It's not a must but would be nice to have this functionality.
I don't think you've addressed my concern... but I'm afraid I haven't been able to properly follow what you're saying.
In any case, applying this patch means that you _permanently_ prevent the reception of ^O on _ANY_ 8250 serial port, whether it be a serial console or not.
With this patch, I guess it's tough luck if you have a modem connected to your PC and you want to run ppp or x,y,z modem protocols.
Quoted 7 lines
Quoted 3 lines
We don't drop the lock when calling
uart_handle_sysrq_char()further down in this function. Why is this needed? Also, why is this needed to be duplicated?You are correct. This is not needed. I have removed this piece of code.
How about the following patch.
I'm still highly concerned about this whole idea. Applying this patch _will_ without doubt inconvenience a lot of people who expect ^O to be received as normal.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 5 lines
Frown. Sorry, I'm not sure what "p615", "power4" and "no-hmc" is. I also don't know what an IBM 3153 is.
Quoted 9 lines
However, you seem to be suggesting that a terminal application somehow forwards the ctrl-sysrq (and it's actually alt-sysrq). Maybe it does, maybe it doesn't. Probably depends on the terminal application itself.
Eg, with minicom, you need to ask minicom to create the serial break event itself, normally by (assuming default configuration) <ctrl-a> <f>.
Sorry about using all those cryptic terms. I was trying to explain with
the help of few test scenario's. I had tested on couple of PowerPC processor
based machines which can be configured either as a standalone machine [ Without any Logical Partitions ] or can be logically partitioned. One can use a Hardware Management console [HMC] to manage the machine.
Quoted 12 lines
I don't think you've addressed my concern... but I'm afraid I haven't been able to properly follow what you're saying.
In any case, applying this patch means that you _permanently_ prevent the reception of ^O on _ANY_ 8250 serial port, whether it be a serial console or not.
With this patch, I guess it's tough luck if you have a modem connected to your PC and you want to run ppp or x,y,z modem protocols.
The point i was trying to make was to have a consistent behavior across
virtual and real consoles connected to certain kind of machines. But as stated by you this patch might cause lot of inconvenience to other user. So it's best not to introduce this patch.
Quoted 2 lines
Quoted 3 lines · Russell King
I'm still highly concerned about this whole idea. Applying this patch _will_ without doubt inconvenience a lot of people who expect ^O to be received as normal.
If one boots with 'console=ttyS0', the 'ctrl o' should be handled only on ttyS0. However, I'm not sure if anyone uses ^O in this situation via the system console. In our case, ttyS0 is automatically activated via add_preferred_console in arch/powerpc/kernel/setup-common.c. If there is a clever way to handle ^O only for the system console, would such a patch be accepted? I'm currently looking through the code to see how it could be done.
Signature · 2 lines
short story of a lazy sysadmin: alias appserv=wotan
Quoted 6 lines · Olaf Hering
Quoted 3 lines · Russell King
I'm still highly concerned about this whole idea. Applying this patch _will_ without doubt inconvenience a lot of people who expect ^O to be received as normal.
Quoted 7 lines
If one boots with 'console=ttyS0', the 'ctrl o' should be handled only on ttyS0. However, I'm not sure if anyone uses ^O in this situation via the system console. In our case, ttyS0 is automatically activated via
add_preferred_consoleinarch/powerpc/kernel/setup-common.c. If there is a clever way to handle ^O only for the system console, would such a patch be accepted? I'm currently looking through the code to see how it could be done.
Easily. Have a look at the internals of uart_handle_break() in include/linux/serial_core.h
However, please be aware that ^O is the default control character for "flush output" which I think is something you may want to use with a serial console. Eg:
speed 38400 baud; rows 0; columns 0; line = 1;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
^^^^^^^^^^^Hence it's a poor choice. Maybe picking a character which isn't already used by default for another purpose would be appropriate? '^]', the classic telnet escape character maybe?
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 2 lines · Russell King
Easily. Have a look at the internals of
uart_handle_break()ininclude/linux/serial_core.h
This one works for me, tested with 2.6.5.
drivers/serial/8250.c | 7 +++++++ 1 files changed, 7 insertions(+)
drivers/serial/8250.c +7 -0
@@ -1154,6 +1154,13 @@ receive_chars(struct uart_8250_port *up,*/ } ch =serial_inp (up,UART_RX ); + +#if defined(CONFIG_MAGIC_SYSRQ ) && defined(CONFIG_SERIAL_CORE_CONSOLE ) +/* Handle the SysRq ^O Hack, but only on the system console */ +if (ch =='\x0f' &&uart_handle_break (&up->port)) + goto ignore_char; +#endif + flag =TTY_NORMAL ; up->port.icount.rx++;
Signature · 2 lines
short story of a lazy sysadmin: alias appserv=wotan