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
