Strange issue after early AP startup

[Hans Petter Selasky]

On 01/17/17 20:46, Ian Lepore wrote:
>>> Does this matter for the first tick? How often is configtimer() called?
>> >
>> > As I said, it is called at runtime when profclock is started / stopped, not
>> > just at boot.  Those changes at runtime probably have existing callouts
>> > active and your change will not process any callouts until the next hardclock
>> > tick fires (but only because you are setting nextcallopt to the bogus
>> > 'next' value).
> On some platforms, configtimer() can be called quite often.  Power
> saving modes can change the frequency of the timer, and systems that
> suppport such dynamic frequency scaling call configtimer()
> (via cpu_et_frequency()) to handle the changes.

Hi,

I propose the following patch then:

diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
index 7f7769d..5ae925b 100644
--- a/sys/kern/kern_clocksource.c
+++ b/sys/kern/kern_clocksource.c
@@ -511,8 +511,13 @@ configtimer(int start)
                         state->nexthard = next;
                         state->nextstat = next;
                         state->nextprof = next;
-                       state->nextcall = next;
-                       state->nextcallopt = next;
+                       /*
+                        * Force callout_process() to be called
+                        * instantly, so that the correct value of
+                        * "nextcall" can be computed:
+                        */
+                       state->nextcall = SBT_MAX;
+                       state->nextcallopt = now + 1;
                         hardclock_sync(cpu);
                 }
                 busy = 0;


Then there is no problem having to wait for the next tick or anything, 
like John Baldwin pointed out.

--HPS