From: Zhang Rui <rui.zhang@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
kvalo@kernel.org,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Linux PM <linux-pm@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
linux-rtc@vger.kernel.org,
"open list:NETWORKING DRIVERS (WIRELESS)"
<linux-wireless@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
merez@codeaurora.org, mat.jonczyk@o2.pl,
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>,
Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 7/7] rtc: cmos: Add suspend/resume endurance testing hook
Date: Wed, 18 May 2022 22:44:46 +0800 [thread overview]
Message-ID: <2dc4aa933d07add206a2aeefa15a4837aca6ff62.camel@intel.com> (raw)
In-Reply-To: <CAJZ5v0jt1OND_d08mC0TC1LZ-JGANDY5fiDmH5RUfdtRk1vZFw@mail.gmail.com>
On Tue, 2022-05-17 at 17:14 +0200, Rafael J. Wysocki wrote:
> On Thu, May 5, 2022 at 3:58 AM Zhang Rui <rui.zhang@intel.com> wrote:
> >
> > Automated suspend/resume testing uses the RTC for wakeup.
> > A short rtcwake period is desirable, so that more suspend/resume
> > cycles can be completed, while the machine is available for
> > testing.
> >
> > But if too short a wake interval is specified, the event can occur,
> > while still suspending, and then no event wakes the suspended
> > system
> > until the user notices that testing has stalled, and manually
> > intervenes.
>
> If the wakeup event occurs while still suspending, it should abort
> the
> suspend in progress, shouldn't it? But the above implies that it
> doesn't do that.
>
> If this is fixed, wouldn't it address the issue at hand?
I think the rootcause of the original problem is that
1. on some systems, the ACPI RTC Fixed event is used during suspend
only, and the ACPI Fixed event is enabled in the rtc-cmos driver
.suspend() callback
and
2. if the RTC Alarm already expires before .suspend() invoked, we will
lose the ACPI RTC Fixed Event as well as the wakeup event, say 20
seconds delay in freeze processes.
But, even if that problem is fixed, the suspend aborts and "fails" as
expected, this is still a problem for the suspend-automation scenario,
because the system actually can suspend successfully if we don't set
the RTC alarm too aggressively. And in PCH overheating case, surely we
will get false alarms, because we will never use a 60s+ rtc alarm for
suspend-automation.
thanks,
rui
next prev parent reply other threads:[~2022-05-18 14:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 1:58 [PATCH 0/7] PM: Solution for S0ix failure caused by PCH overheating Zhang Rui
2022-05-05 1:58 ` [PATCH 1/7] PM: wakeup: expose pm_wakeup_pending to modules Zhang Rui
2022-05-05 1:58 ` [PATCH 2/7] thermal: intel: pch: enhance overheat handling Zhang Rui
2022-05-17 15:02 ` Rafael J. Wysocki
2022-05-05 1:58 ` [PATCH 3/7] thermal: intel: pch: improve the cooling delay log Zhang Rui
2022-05-05 1:58 ` [PATCH 4/7] ACPI: video: improve PM notifer callback Zhang Rui
2022-05-05 1:58 ` [PATCH 5/7] wil6210: remove debug message for unsupported PM event Zhang Rui
2022-05-05 4:38 ` Kalle Valo
2022-05-05 5:24 ` Zhang Rui
2022-05-06 14:04 ` Kalle Valo
2022-05-07 1:23 ` Zhang Rui
2022-05-05 1:58 ` [PATCH 6/7] PM: suspend: introduce PM_SUSPEND_LATE event Zhang Rui
2022-05-05 1:58 ` [PATCH 7/7] rtc: cmos: Add suspend/resume endurance testing hook Zhang Rui
2022-05-06 21:46 ` Alexandre Belloni
2022-05-07 2:00 ` Zhang Rui
2022-05-07 7:31 ` Alexandre Belloni
2022-05-07 7:41 ` Zhang Rui
2022-05-16 7:50 ` Zhang Rui
2022-05-17 15:14 ` Rafael J. Wysocki
2022-05-18 14:44 ` Zhang Rui [this message]
2022-05-18 15:02 ` Rafael J. Wysocki
2022-05-18 16:07 ` Zhang Rui
2022-05-19 2:33 ` Len Brown
2022-05-19 10:56 ` Rafael J. Wysocki
2022-05-05 8:22 ` [PATCH 0/7] PM: Solution for S0ix failure caused by PCH overheating Oliver Neukum
2022-05-05 12:02 ` Rafael J. Wysocki
2022-05-05 15:18 ` Zhang Rui
2022-05-17 15:11 ` Rafael J. Wysocki
2022-05-17 17:07 ` Alexandre Belloni
2022-05-18 14:11 ` Zhang Rui
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=2dc4aa933d07add206a2aeefa15a4837aca6ff62.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=alexandre.belloni@bootlin.com \
--cc=daniel.lezcano@linaro.org \
--cc=kvalo@kernel.org \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mat.jonczyk@o2.pl \
--cc=merez@codeaurora.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sumeet.r.pawnikar@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;
as well as URLs for NNTP newsgroup(s).