Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jan 2017 22:28:47 +0100
From:      Hans Petter Selasky <hps@selasky.org>
To:        Ian Lepore <ian@freebsd.org>, John Baldwin <jhb@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org>
Subject:   Re: Strange issue after early AP startup
Message-ID:  <11f27a15-f9bc-8988-a17e-78aeff1745fb@selasky.org>
In-Reply-To: <1484682389.86335.166.camel@freebsd.org>
References:  <b9c53237-4b1a-a140-f692-bf5837060b18@selasky.org> <2215603.KuBd8pM5Pm@ralph.baldwin.cx> <3cbe6454-82cc-0592-4ee6-3c1552b19f9a@selasky.org> <4212167.Wq8tLU1ohU@ralph.baldwin.cx> <1484682389.86335.166.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11f27a15-f9bc-8988-a17e-78aeff1745fb>