[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <877bt1lpx4.fsf@jogness.linutronix.de>
Date: Wed, 28 Jan 2026 16:31:59 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>, ysard <ysard_git@....fr>
Cc: linux-kernel@...r.kernel.org, senozhatsky@...omium.org
Subject: Re: Regression: system freeze on resume from suspend introduced by
printk per-console suspended state
On 2026-01-28, Petr Mladek <pmladek@...e.com> wrote:
> But I have found a bug in John's debug patch from
> https://lore.kernel.org/all/877bts1ltv.fsf@jogness.linutronix.de/
>
> The patch tried to restore the original behavior on current mainline.
> But console_suspend()/cosnole_resume() function have been renamed recently
> to console_suspend_all()/console_resume_all(). The original
> names were used for console-specific suspend/resume variants,
> see
> https://lore.kernel.org/all/20250226-printk-renaming-v1-0-0b878577f2e6@suse.com/
>
> Also the debug patch did not revert synchronize_srcu(). I guess that
> this was intentional.
I was also concerned about synchronize_srcu() being the culprit, which
is why I left it in. I was really surprised the test patch still had
problems.
> But I would rather revert it as well because
> it is a potentially blocking operation.
>
> Could you please test it with this fixed version of the debug patch?
>
> If the patch helps, by chance, then please try to uncomment
> the synchronize_srcu() calls and check if it still works.
Also, if the patch still has the problem, it would be nice to see the
dmesg output with the patch applied when you do only the nvidia
suspend/resume and avoid systemctl.
> I wonder if they make in difference.
Thanks Petr for the new patch version. I am curious what comes of it.
John
Powered by blists - more mailing lists