On Fri, Dec 13 2024 at 09:43, David Woodhouse wrote: > 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.464961] schedule+0x3a/0x140 > [ 113.465234] schedule_timeout+0xcc/0x110 > [ 113.465580] __wait_for_common+0x91/0x1c0 > [ 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 That's the control thread on CPU0. The hotplug thread on CPU1 is stuck here: task:cpuhp/1 state:D stack:0 pid:24 tgid:24 ppid:2 flags:0x00004000 Call Trace: <TASK> __schedule+0x51f/0x1a80 schedule+0x3a/0x140 schedule_timeout+0x90/0x110 msleep+0x2b/0x40 blk_mq_hctx_notify_offline+0x160/0x3a0 cpuhp_invoke_callback+0x2a8/0x6c0 cpuhp_thread_fun+0x1ed/0x270 smpboot_thread_fn+0xda/0x1d0 So something with those blk_mq fixes went sideways. Thanks, tglx