Re: test 1: was: Re: A Comparison of printk between upstream and linux-rt-devel

[Petr Mladek <pmladek@suse.com>]

On Mon 2024-08-26 10:46:52, Derek Barbosa wrote:
> On Mon, Aug 26, 2024 at 04:02:34PM +0200, Petr Mladek wrote:
> > > If you have any other questions, please let me know. I would be happy to re-do
> > > these tests with different kernels, configs + other variables and controls.
> > 
> > It might be interesting to redo the 1st test without the crashdump.
> > I wonder if console_flush_on_panic() would allow to see the panic
> > backtrace with the stock kernel.
> 
> Sure. 
> 
> I disabled the systemd kdump service unit via systemctl, and performed a reboot
> to ensure that the crashkernel would not be armed.
> 
> Performing a trial run of console_blast.sh shows results similar to what was
> documented previously, with the difference being we don't reboot after the test
> is completed and the kernel has effectively "crashed" via the sysrq-trigger.
>
> I have appended the serial console output as an attachment. You will see that we
> do not get a final trace printed.
>
> [   98.341743] sysrq: Show State
> [   98.341746] sysrq: Show State
> [   98.341805] sysrq: Show State
> [   98.341808] sysrq: Show State
> [   98.341812] task:systemd         state:S
> [   98.341814] task:systemd         state:S
> [   98.341814]  stack:0     pid:1     tgid:1     ppid:0      flags:0x00000002
> [   98.341818]  stack:0     pid:1     tgid:1     ppid:0      flags:0x00000002
[...]
> [  111.777491]  ? __pfx_hrtimer_wakeup+0x10/0x10
> ** 8555 printk messages dropped **
> [  111.807996]  ? __lruvec_stat_mod_folio+0x86/0xd0
> 

I see. I guess that the panic CPU ended in a deadlock in
console_flush_on_panic() after it ignored the console_lock().
Otherwise, it would have flushed the last messages and rebooted.

Best Regards,
Petr