Re: Regression: system freeze on resume from suspend introduced by printk per-console suspended state

[John Ogness]

 On 2026-01-08, pv <pierre.vignet@xxxxxxxxxxx> wrote:
> The code in 6.18.2 has changed enough that I don't dare change it as I did in 6.7.
> After compiling and installing 6.19-rc1 (8f0b4cce4481fb22653697cced8d0d04027cb1e8),
> I can confirm that the freeze is still present.

Thanks for confirmation. Would you be willing to try a debugging patch?

I have attached a patch (based on 6.19-rc4). It should restore the old
console_lock behavior during suspend/resume. Assuming this works for
you, it also adds some debugging information so that we can figure out
who is locking the console.

Please compile with CONFIG_PRINTK_CALLER=y.

After suspend/resume, locate the debug lines with:

# dmesg | grep printk

It will probably look something like this:

# dmesg | grep printk
[   12.085727][  T843] printk: Suspending console(s) (use no_console_suspend to debug)
[   12.236199][  T843] printk: console_suspend
[   17.581734][   T67] printk: console_lock
[   17.583711][   T67] printk: console_unlock
[   17.644819][  T843] printk: console_lock
[   17.644823][  T843] printk: console_unlock
[   17.644827][  T843] printk: console_resume

If you have CONFIG_PRINTK_CALLER enabled (as I do here), it will show
the tasks locking the console. In my case it is PID 67 and 843. It would
be nice to know who these are. For me it is:

# cat /proc/67/comm
kworker/2:1-mm_percpu_wq

# cat /proc/843/comm
sh

So in summary, I would like to know:

1. Does suspend/resume work on 6.19-rc4 with this patch applied?

2. Output of "dmesg | grep printk" (after suspend/resume)

3. Which tasks were locking the console between console_suspend and
console_resume?

Your help in debugging this is greatly appreciated.

John Ogness