It appears that this behaviour is as expected. It is entirly reasonable
to want to trigger a sysrq and read it from the dmesg/syslog without
spamming the console.
The documentation is below par here, so I have pushed up some
documentation updates to mainline to make this more obvious.
** Changed
As it is not clear what the correct behaviour is, and that documentation
at a minimum is needed I have started a thread on lkml to discuss the
correct option.
--
SysRq output not going to the console
https://bugs.launchpad.net/bugs/314681
You received this bug notification because you are a membe
Looking at the source this seems to have always been the way things
were. That this is intentional. This is likely because some consoles
are very slow (such as serial) and the output will be in dmesg at least.
As turning loglevel up to do the dump (the equivalent of sysrq doing it
automatically)
It seems that the header only behaviour is triggered by the loglevel of
the kernel being low due to the kernel command line option 'quiet'. You
can modify the running kernel loglevel using sysrq-8 and then later
sysrq commands should be visible. You may want to return loglevel to
normal later; sys
I can confirm the same behaviour here on my laptop. Hitting any sysrq
combination outputs the header on the raw console and nothing else. The
dmesg bufffer contains the full output.
As a work around you migth be able to use dmesg directly to get the
output?
** Changed in: ubuntu
Status:
