On Fri, Dec 13 2024 at 19:09, Ming Lei wrote: > On Fri, Dec 13, 2024 at 11:42:59AM +0100, Thomas Gleixner wrote: >> 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. > > The cpuhp callback is just waiting for inflight IOs to be completed when > the irq is still live. > > It looks same with the following report: > > https://lore.kernel.org/linux-scsi/F991D40F7D096653+20241203211857.0291ab1b@john-PC/ > > Still triggered in case of kexec & qemu, which should be one qemu > problem. I'd rather say, that's a kexec problem. On the same instance a loop test of suspend to ram with pm_test=core just works fine. That's equivalent to the kexec scenario. It goes down to syscore_suspend() and skips the actual suspend low level magic. It then resumes with syscore_resume() and brings the machine back up. That runs for 2 hours now, while the kexec muck dies within 2 minutes.... And if you look at the difference of these implementations, you might notice that kexec just implemented some rudimentary version of the actual suspend logic. Based on let's hope it works that way. This is just insane and should be rewritten to actually reuse the suspend mechanism, which is way better tested than this kexec jump muck. Thanks, tglx
