Stefan Sperling <s...@stsp.name> wrote:
> On Thu, Jul 31, 2025 at 10:35:49AM -0600, Theo de Raadt wrote:
> > > Modified files:
> > > sys/kern : subr_suspend.c
> > >
> > > Log message:
> > > Give the resume_time check in resuming() more headroom.
> > >
> > > On the Z13 resume by power button will usually trigger an immediate
> > > shutdown after resume. When resume succeeds the headroom provided by
> > > resume_time + 10 is between 1 to 3 seconds, which is a bit close.
> > > Set the ceiling to resume + 15 to give us more time to finish resuming.
> > >
> > > ok kettenis@
> >
> > That is surprising.
> >
> > Are we setting resume_time too early?
>
> The Z13 problem can also be fixed like this, which should not cause
> additional penalty for machines which resume fast:
> @@ -55,6 +55,7 @@ sleep_state(void *v, int sleepmode)
> extern int perflevel;
> size_t rndbuflen;
> char *rndbuf;
> + time_t now;
> #ifdef GPROF
> int gmon_state;
> #endif
> @@ -218,11 +219,18 @@ fail_hiballoc:
> cpu_setperf(perflevel); /* Restore hw.setperf */
> if (suspend_finish(v) == EAGAIN)
> goto top;
> + /*
> + * Rearm the power-button timeout if we have spent
> + * a significant amount of time until here.
> + */
> + now = getuptime();
> + if (resume_time + 5 < now)
> + resume_time = now;
> return (error);
> }
I don't see why you need the conditional. Just set it again, which
is one line:
resume_time = getuptime();
Is there a reason to not do that?
There are two issues being solved. One is blocking kernel behaviors
during the time when the kernel is fully in control. The second issue
is ignoring the user's requests. If the timer is simply extended
once the kernel-resume parts have finished, we get a nice 10 second
block on user interaction on all machines.
