Re: test 1: was: Re: A Comparison of printk between upstream and linux-rt-devel
From: Petr Mladek
Date: Mon Aug 26 2024 - 11:10:38 EST
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