Strange issue after early AP startup
Hans Petter Selasky
hps at selasky.org
Thu Jan 19 08:24:23 UTC 2017
On 01/18/17 09:00, Hans Petter Selasky wrote:
> On 01/18/17 02:18, John Baldwin wrote:
>> You might still want to adjust 'nextevent' to schedule the next interrupt
>> to be sooner than 'timerperiod' though. You could just set
>> 'nextevent' to
>> 'now' in that case instead of 'next'.
>
> Right, I'll give that a spin. Would have to be "now + 1" instead of
> "now", due to check before et_start() ?
>
Hi John,
Here is another variant of my patch which solves the EARLY AP startup
problem with timers. What do you think?
> diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
> index 7f7769d..8bacff6 100644
> --- a/sys/kern/kern_clocksource.c
> +++ b/sys/kern/kern_clocksource.c
> @@ -207,7 +207,7 @@ handleevents(sbintime_t now, int fake)
> }
> } else
> state->nextprof = state->nextstat;
> - if (now >= state->nextcallopt) {
> + if (now >= state->nextcallopt || now >= state->nextcall) {
> state->nextcall = state->nextcallopt = SBT_MAX;
> callout_process(now);
> }
I can add prints/asserts to show that what happens is that
"state->nextcallopt > now" while "state->nextcall <= now". This
situtation is allowed to persist due to the way getnextcpuevent() is
currently implemented.
Can the people CC'ed give the attached patch a spin and report back?
--HPS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timer_init_fix2.diff
Type: text/x-patch
Size: 456 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170119/d810d8c1/attachment.bin>
More information about the freebsd-current
mailing list