On Fri, 2024-12-13 at 09:31 +0000, David Woodhouse wrote:
>
> (gdb) p sysrq_handle_showstate('t')
>
> That didn't work. Maybe if I'd actually had no_console_suspend on this
> boot. Will try again.
With your fix I get the same thing (both CPUs in idle thread). And with
no_console_suspend on the command line, 'p sysrq_handle_showstate('t')'
does work...
[ 113.462898] task:loadret state:D stack:0 pid:707 tgid:707 ppid:531 flags:0x00004002
[ 113.463615] Call Trace:
[ 113.463841] <TASK>
[ 113.464029] __schedule+0x502/0x1a10
[ 113.464331] ? find_held_lock+0x2b/0x80
[ 113.464661] ? schedule+0xea/0x140
[ 113.464961] schedule+0x3a/0x140
[ 113.465234] schedule_timeout+0xcc/0x110
[ 113.465580] __wait_for_common+0x91/0x1c0
[ 113.465923] ? __pfx_schedule_timeout+0x10/0x10
[ 113.466304] cpuhp_kick_ap_work+0x13e/0x390
[ 113.466657] _cpu_down+0xd4/0x370
[ 113.466936] freeze_secondary_cpus.cold+0x3f/0xd4
[ 113.467326] kernel_kexec+0xa2/0x1a0
[ 113.467634] __do_sys_reboot+0x206/0x250
[ 113.467974] do_syscall_64+0x95/0x180
[ 113.468266] ? kfree+0xdb/0x3a0
[ 113.468542] ? __x64_sys_kexec_load+0xa9/0xe0
[ 113.468906] ? kfree+0xdb/0x3a0
[ 113.469177] ? do_kexec_load+0x120/0x340
[ 113.469525] ? lockdep_hardirqs_on_prepare+0xdb/0x190
[ 113.469940] ? syscall_exit_to_user_mode+0x97/0x290
[ 113.470338] ? do_syscall_64+0xa1/0x180
[ 113.470667] ? trace_hardirqs_off+0x4b/0xc0
[ 113.471021] ? lockdep_hardirqs_on_prepare+0xdb/0x190
[ 113.471414] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
