From: John Ogness <john.ogness@linutronix.de>
To: pv <pierre.vignet@caramail.fr>, ysard_git@gmx.fr
Cc: linux-kernel@vger.kernel.org, pmladek@suse.com, senozhatsky@chromium.org
Subject: Re: Regression: system freeze on resume from suspend introduced by printk per-console suspended state
Date: Thu, 08 Jan 2026 10:49:24 +0106 [thread overview]
Message-ID: <877bts1ltv.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <trinity-4a9c7cd3-cb54-452e-9d51-0fb5bdac8c0c-1767830742679@3c-app-mailcom-bs14>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
On 2026-01-08, pv <pierre.vignet@caramail.fr> 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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-printk-Debug-new-vs.-old-suspend-resume-behavior.patch --]
[-- Type: text/x-diff, Size: 3581 bytes --]
From f3bb7d49b59b61a30f2fefc2b241d3f535b2afd2 Mon Sep 17 00:00:00 2001
From: John Ogness <john.ogness@linutronix.de>
Date: Thu, 8 Jan 2026 09:31:51 +0000
Subject: [PATCH] printk: Debug new vs. old suspend/resume behavior
This is just for debugging. It should restore the old console_lock
behavior for suspend/resume and also adds some debugging information.
Please compile with CONFIG_PRINTK_CALLER=y so that we can see which
tasks are locking/unlocking the console during suspend/resume.
---
kernel/printk/printk.c | 61 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1d765ad242b8..fd69cab4368e 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -356,6 +356,22 @@ static void __up_console_sem(unsigned long ip)
*/
static int console_locked;
+static int console_suspended;
+
+int vprintk_store(int facility, int level,
+ const struct dev_printk_info *dev_info,
+ const char *fmt, va_list args);
+
+/* Helper function to store-only. */
+static void printk_store(const char *fmt, ...)
+{
+ va_list args;
+
+ va_start(args, fmt);
+ vprintk_store(0, LOGLEVEL_DEFAULT, NULL, fmt, args);
+ va_end(args);
+}
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -2841,6 +2857,15 @@ void console_lock(void)
msleep(1000);
down_console_sem();
+ if (console_suspended) {
+ printk_store(KERN_INFO "printk: %s\n", __func__);
+ /*
+ * Keep console locked, but do not touch
+ * @console_locked or @console_may_schedule.
+ * (Although they will both be 1 here anyway.)
+ */
+ return;
+ }
console_locked = 1;
console_may_schedule = 1;
}
@@ -2861,6 +2886,15 @@ int console_trylock(void)
return 0;
if (down_trylock_console_sem())
return 0;
+ if (console_suspended) {
+ printk_store(KERN_INFO "printk: %s\n", __func__);
+ /*
+ * The lock was acquired, but unlock directly and report
+ * failure. Here console_locked=1 and console_may_schedule=1.
+ */
+ up_console_sem();
+ return 0;
+ }
console_locked = 1;
console_may_schedule = 0;
return 1;
@@ -3354,6 +3388,16 @@ void console_unlock(void)
{
struct console_flush_type ft;
+ if (console_suspended) {
+ printk_store(KERN_INFO "printk: %s\n", __func__);
+ /*
+ * Simply unlock directly.
+ * Here console_locked=1 and console_may_schedule=1.
+ */
+ up_console_sem();
+ return;
+ }
+
printk_get_console_flush_type(&ft);
if (ft.legacy_direct)
__console_flush_and_unlock();
@@ -3559,6 +3603,7 @@ struct tty_driver *console_device(int *index)
void console_suspend(struct console *console)
{
__pr_flush(console, 1000, true);
+
console_list_lock();
console_srcu_write_flags(console, console->flags & ~CON_ENABLED);
console_list_unlock();
@@ -3570,6 +3615,12 @@ void console_suspend(struct console *console)
* using the port.
*/
synchronize_srcu(&console_srcu);
+
+ console_lock();
+ console_suspended = 1;
+ printk_store(KERN_INFO "printk: %s\n", __func__);
+ /* Unlock directly (i.e. without clearing @console_locked). */
+ up_console_sem();
}
EXPORT_SYMBOL(console_suspend);
@@ -3597,6 +3648,16 @@ void console_resume(struct console *console)
defer_console_output();
__pr_flush(console, 1000, true);
+
+ down_console_sem();
+ printk_store(KERN_INFO "printk: %s\n", __func__);
+ console_suspended = 0;
+ /*
+ * Perform a regular unlock.
+ * Here console_locked=1 and console_may_schedule=1.
+ * @console_unlocked will be cleared.
+ */
+ console_unlock();
}
EXPORT_SYMBOL(console_resume);
--
2.30.2
next prev parent reply other threads:[~2026-01-08 9:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-21 22:42 Regression: system freeze on resume from suspend introduced by printk per-console suspended state ysard_git
2025-12-23 6:20 ` John Ogness
[not found] ` <trinity-43147d5d-a8ea-47c1-9f83-b578c346b387-1766479103562@3c-app-mailcom-bs12>
2026-01-08 0:05 ` pv
2026-01-08 9:43 ` John Ogness [this message]
2026-01-23 7:44 ` ysard
2026-01-23 12:19 ` Petr Mladek
2026-01-24 1:22 ` ysard
2026-01-28 14:00 ` Petr Mladek
2026-01-28 15:25 ` John Ogness
2026-01-29 9:34 ` ysard
2026-01-30 15:56 ` Petr Mladek
2026-01-30 16:28 ` Petr Mladek
2026-01-31 22:22 ` ysard
2026-02-02 11:02 ` Petr Mladek
2026-02-03 1:32 ` ysard
2026-02-03 14:11 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877bts1ltv.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre.vignet@caramail.fr \
--cc=pmladek@suse.com \
--cc=senozhatsky@chromium.org \
--cc=ysard_git@gmx.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox