http://bugzilla.novell.com/show_bug.cgi?id=1104792 http://bugzilla.novell.com/show_bug.cgi?id=1104792#c6 --- Comment #6 from Petr Mladek <pmladek@suse.com> --- (In reply to Oliver Kurz from comment #4)

What I see:

* openSUSE Leap 42.3: works, /proc/sys/kernel/printk: 4 4 1 7 and /sys/module/printk/parameters/ignore_loglevel: N

Strange. I see _no_ output with "sysrq-l" openSUSE Leap 42.3 with the same setting as you. It is because the console handling is deferred in SUSE's kernel-4.4 (avoid softlockups, bug 744692). As a result it does not help to temporarily increase the loglevel in __handle_sysrq()). The messages are handled later and filtered by the original loglevel (4). I wonder why you saw the expected behavior. Have you tried "sysrq-l" in panic situation or in a normal system state?

* openSUSE Leap 15.0: does not work, /proc/sys/kernel/printk: 4 4 1 7 and /sys/module/printk/parameters/ignore_loglevel: N

I could see only the sysrq header line here. If I get it correctly, you saw the same. It is because the kernel 4.12 prevents the softlockups another way. The console is deferred only when more CPUs are calling printk in parallel. The temporary increased loglevel (in __handle_sysrq()) allows to see the header line. The other lines are not visible because the real handler is called with the original loglevel.

* SLE 12 SP4 RC2c1 (build 0421, linux 4.12.14-94.38-default): does not work, /proc/sys/kernel/printk: 7(!) 4 1 7 and /sys/module/printk/parameters/ignore_loglevel: N

I looked at SLE12 SP4 GM default installation. I see the same behavior as with openSUSE Leap 15.0. The explanation is the same as well. Note that I see "1 4 1 7" in /proc/sys/kernel/printk. The log level "1" is forced by rsyslogd, see the bug #593699. I am not sure why you saw "7" in rc2c1.

However, on SLE12SP4 I noticed now one strange thing which I can reproduce on that system but not on my openSUSE Leap 15.0 system: On tty1 When I send sysrq-w it shows only the header line as in the initial report. When I press sysrq-t it shows the message "This sysrq operation is disabled.". However, after this message the next press of sysrq-w shows also the content, not just the header! This works until next reboot (or maybe console switch?).

Great catch! There is a bug. The original loglevel is not restored in __handle_sysrq() when the message about disabled sysrq operation is printed. As a result, the console stays verbose. I am going to send a patch upstream for this. -- You are receiving this mail because: You are on the CC list for the bug.