Comment # 6 on bug 1104792 from Petr Mladek

(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.