On Wed, May 18, 2022 at 4:45 PM Zhang Rui <rui.zhang@xxxxxxxxx> wrote: > > 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@xxxxxxxxx> 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. Well, the RTC Fixed event can be armed in a PM/HIBERNATE notifier and if it fires before .suspend() runs, system wakeup can be triggered from there. > 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. I'm not sure why this is a problem. It only means that occasionally the system will not reach the final "suspended" state, but that can happen regardless.
