Re: Strange issue after early AP startup

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
 > _at__at_ -207,7 +207,7 _at__at_ 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