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. 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
