Message-ID: <87tsxhbtxo.fsf@jogness.linutronix.de>
Date: Tue, 23 Dec 2025 07:26:35 +0106
From: John Ogness <john.ogness@...utronix.de>
To: ysard_git@....fr, linux-kernel@...r.kernel.org
Cc: pmladek@...e.com, senozhatsky@...omium.org
Subject: Re: Regression: system freeze on resume from suspend introduced by
 printk per-console suspended state

Hi,

On 2025-12-21, ysard_git@....fr wrote:
> I would like to report a suspend/resume regression which I bisected down
> to a specific printk commit.

Thanks for the report and your efforts to isolate the commit! Comments
below...

> Summary
> =======
>
> On an ASUS laptop, resuming from suspend leads to a complete system freeze:
> black screen, no keyboard response. The system must be powered off forcibly.
>
> This regression is reproducible and was introduced by the following commit:
>
> 9e70a5e109a4a ("printk: Add per-console suspended state")
>
> Hardware / environment
> ======================
>
> - Laptop: G75VX ASUS
> - CPU Arch: x86_64
> - BIOS Information
>     Version: G75VX.206
>     Release Date: 02/27/2013
> - GPU: NVIDIA GeForce GTX 670MX (standalone board only, no integrated chip, no optimus)
>     Driver Version: 470.256.02
> - Suspend mode: suspend-to-RAM (S3)
> - Distribution: Debian Testing derivative (but the regression is reproduced with mainline kernel builds)
> - Last working kernel from Debian:
>     Linux version 6.5.0-5-amd64 (debian-kernel@...ts.debian.org)
>     (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41)
>     #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29)
> - Kernel config: based on defconfig / Debian config
> - Taint flag: yes, only Nvidia proprietary drivers are loaded and compiled via DKMS
>
> Symptoms
> ========
>
> - On resume from suspend to RAM
> - Screen remains black
> - No visible kernel panic (no logs)
> - System is completely frozen (no VT switch, no Caps lock nor Num lock responses)
> - Power cycle required
>
> Regression details
> ==================
>
> Suspend/resume works correctly with kernels prior to this commit.
> After this commit, resume consistently results in a hard freeze.
>
> I performed a git bisect on the upstream kernel repository. The result is:
>
> 9e70a5e109a4a23367810de09be826c52d27ee2f is the first bad commit
>
> Commit details:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9e70a5e109a4a23367810de09be826c52d27ee2f
>
> Reverting this commit on a later kernel (v6.7 0dd3ee31125508cd67f7e7172247f05b7fd1753a)
> restores correct suspend/resume behavior on this machine.

Interesting. This commit removes an ugly console_lock hack to supress
console flushing during the suspend/resume window.

> The problem is still present on stable v6.18.2.

It is great that you can reproduce it with 6.18.2. Are you also able to
test 6.19-rc1 and reproduce it? It would be nice to attack the problem
from the latest code first.

> Additional notes
> ================
>
> By playing around with the tests in /sys/power/, I can say that the problem only
> occurs during a real S3 and not a simulated one.
>
> No problem on resume:
> $ echo core > /sys/power/pm_test
> $ echo deep > /sys/power/mem_sleep
> $ systemctl suspend
>
> Freeze on resume:
> $ echo none > /sys/power/pm_test
> $ echo deep > /sys/power/mem_sleep
> $ systemctl suspend
>
> The issue appears hardware-dependent and may be related to the interaction
> between printk console usability and resume ordering. The system likely
> blocks silently during resume before the graphics stack becomes usable.
>
> If additional debugging, logs, or testing are needed, I am available to
> provide them.

It would be helpful to know if you are doing anything special (like
using "no_console_suspend") or have multiple consoles. Could you send
the output of:

$ cat /proc/consoles

   and 

$ cat /proc/cmdline

Once we have this information, we can start to dig deeper.

John Ogness

Powered by blists - more mailing lists