From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
todd.e.brandt@linux.intel.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: PNP0501 serial driver takes almost 2 seconds to suspend/resume (printk issue)
Date: Mon, 11 Jul 2022 10:13:27 +0200 [thread overview]
Message-ID: <Ysvbp8vz7R9hDNqx@alley> (raw)
In-Reply-To: <87o7xwbuoy.fsf@jogness.linutronix.de>
On Sun 2022-07-10 22:10:45, John Ogness wrote:
> On 2022-07-10, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >> Looking at freeze-5.19.0-rc1-bad.html, at 3431.221039 we see that
> >> suspend_console() was called. The additional 1-second delay you are
> >> referring to would be 3432.436187, where serial is
> >> suspended. pr_flush() would have been satisfied when the message at
> >> 3431.221039 was printed. So the question is, why is there still
> >> printing going on?
> >
> > It might be no_console_suspend hack. Are you, btw, aware of this ugly
> > hack in the kernel?
>
> I am aware of it. There are some cases where it actually works. But it
> is not being used here. The boot args are:
>
> BOOT_IMAGE=/boot/vmlinuz-5.19.0-rc1+ root=UUID=1dfec046-baf6-4f38-8b5e-a8f438a48038 ro rw quiet console=ttyS0,115200 console=tty0 i915.enable_psr=1 initcall_debug log_buf_len=32M quiet splash console=tty0 console=ttyS0,115200n8 vt.handoff=7
>
> I am curious if Todd sees this problem with 5.19-rc4 or later (the
> kthread printers were removed).
We removed the kthreads but not pr_flush(). The commit
3b604ca81202eea2a91 ("printk: add pr_flush()") is still there.
It seems that __pr_flush() does not check whether all consoles
are suspended. In this case the progress is not possible and
it has to wait the entire timeout.
Best Regards,
Petr
next prev parent reply other threads:[~2022-07-11 8:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 20:31 PNP0501 serial driver takes almost 2 seconds to suspend/resume (printk issue) Todd Brandt
2022-07-07 20:45 ` Todd Brandt
2022-07-08 8:01 ` John Ogness
2022-07-08 21:35 ` Todd Brandt
2022-07-09 20:41 ` John Ogness
2022-07-10 19:39 ` Andy Shevchenko
2022-07-10 20:04 ` John Ogness
2022-07-11 8:13 ` Petr Mladek [this message]
2022-07-11 10:10 ` Sergey Senozhatsky
2022-07-13 9:51 ` John Ogness
2022-07-13 14:24 ` Todd Brandt
2022-07-13 17:11 ` Todd Brandt
2022-07-13 18:23 ` Todd Brandt
2022-07-13 21:22 ` John Ogness
2022-07-13 22:01 ` John Ogness
2022-07-14 22:16 ` Todd Brandt
2022-07-15 6:14 ` John Ogness
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=Ysvbp8vz7R9hDNqx@alley \
--to=pmladek@suse.com \
--cc=andy.shevchenko@gmail.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=todd.e.brandt@linux.intel.com \
/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