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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.