From: "Linux regression tracking #adding (Thorsten Leemhuis)" <regressions@leemhuis.info>
To: Linux kernel regressions list <regressions@lists.linux.dev>
Cc: linux-serial@vger.kernel.org, thomas.richard@bootlin.com
Subject: Re: Regression: serial: 8250_omap: error during suspend if no_console_suspend is set
Date: Wed, 20 Sep 2023 16:36:17 +0200 [thread overview]
Message-ID: <33bf96d0-fbe0-dfb4-a791-233f49f9080d@leemhuis.info> (raw)
In-Reply-To: <8a856171-e743-737e-eb9d-42852e4e4f19@bootlin.com>
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[Note: part of this is now handled here:
https://lore.kernel.org/all/59b13c93-6637-3050-c145-31be0d6c12c9@bootlin.com/]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.]
On 14.09.23 18:26, Thomas Richard wrote:
>
> After switching to Linux 6.6-rc1, i met an issue during suspend to idle
> with 8250_omap driver (no_console_suspend is set).
> The driver fails to suspend the uart port used for the serial console so
> the suspend sequence is stopped.
>
> [ 114.629197] port 2800000.serial:0.0: PM: calling
> pm_runtime_force_suspend+0x0/0x134 @ 114, parent: 2800000.serial:0
> [ 114.639617] port 2800000.serial:0.0: PM:
> pm_runtime_force_suspend+0x0/0x134 returned 0 after 2 usecs
> [ 114.648739] omap8250 2800000.serial: PM: calling
> omap8250_suspend+0x0/0xf4 @ 114, parent: bus@100000
> [ 114.657861] omap8250 2800000.serial: PM: dpm_run_callback():
> omap8250_suspend+0x0/0xf4 returns -16
> [ 114.666808] omap8250 2800000.serial: PM: omap8250_suspend+0x0/0xf4
> returned -16 after 8951 usecs
> [ 114.675580] omap8250 2800000.serial: PM: failed to suspend: error -16
> [ 114.682011] PM: suspend of devices aborted after 675.644 msecs
> [ 114.687833] PM: start suspend of devices aborted after 681.777 msecs
> [ 114.694175] PM: Some devices failed to suspend, or early wake event
> detected
>
> The following sequence is used to suspend to idle:
> $ echo 1 > /sys/power/pm_debug_messages
> $ echo 1 > /sys/power/pm_print_times
> $ echo 8 > /proc/sys/kernel/printk
> $ echo 0 > /sys/module/printk/parameters/console_suspend
> $ echo enabled >
> /sys/devices/platform/bus@100000/2800000.serial/tty/ttyS2/power/wakeup
> $ echo s2idle > /sys/power/mem_sleep
> $ echo mem > /sys/power/state
>
> The regression was introduced in commit 20a41a62618d "serial: 8250_omap:
> Use force_suspend and resume for system suspend"
>
> Before commit 20a41a62618d, omap8250_suspend returned 0.
> Now pm_runtime_force_suspend is called and its return code is used by
> omap8250_suspend.
>
> static int omap8250_suspend(struct device *dev)
> {
> struct omap8250_priv *priv = dev_get_drvdata(dev);
> struct uart_8250_port *up = serial8250_get_port(priv->line);
> int err;
>
> serial8250_suspend_port(priv->line);
>
> err = pm_runtime_resume_and_get(dev);
> if (err)
> return err;
> if (!device_may_wakeup(dev))
> priv->wer = 0;
> serial_out(up, UART_OMAP_WER, priv->wer);
> err = pm_runtime_force_suspend(dev);
> flush_work(&priv->qos_work);
>
> return err;
> }
>
> The pm_runtime_force_suspend function calls omap8250_runtime_suspend
> which returns -EBUSY because console suspend was disabled (which is my
> case), as explained in the code.
>
> /*
> * When using 'no_console_suspend', the console UART must not be
> * suspended. Since driver suspend is managed by runtime suspend,
> * preventing runtime suspend (by returning error) will keep device
> * active during suspend.
> */
> if (priv->is_suspending && !console_suspend_enabled) {
> if (up && uart_console(&up->port))
> return -EBUSY;
> }
>
> The port is used by the console, so we don't want to suspend it (console
> suspend was disabled).
> Of course, if console_suspend is enabled and messages are disabled there
> is no issue.
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced 20a41a62618d
#regzbot title serial: 8250_omap: suspend issue with console_suspend
disabled
#regzbot monitor:
https://lore.kernel.org/all/59b13c93-6637-3050-c145-31be0d6c12c9@bootlin.com/
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
next prev parent reply other threads:[~2023-09-20 14:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 16:26 Regression: serial: 8250_omap: error during suspend if no_console_suspend is set Thomas Richard
2023-09-18 7:35 ` Greg KH
2023-09-21 7:37 ` Thomas Richard
2023-09-20 14:36 ` Linux regression tracking #adding (Thorsten Leemhuis) [this message]
2023-10-16 8:48 ` Linux regression tracking #update (Thorsten Leemhuis)
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=33bf96d0-fbe0-dfb4-a791-233f49f9080d@leemhuis.info \
--to=regressions@leemhuis.info \
--cc=linux-serial@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=thomas.richard@bootlin.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;
as well as URLs for NNTP newsgroup(s).