Date: Thu, 19 Jan 2017 09:23:39 +0100 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, Jia-Shiun Li <jiashiun@gmail.com> Subject: Re: Strange issue after early AP startup Message-ID: <f675e822-afce-b666-72ca-9a6ea77209e5@selasky.org> In-Reply-To: <24593c49-b0d5-8aaf-e11b-bfef4704267e@selasky.org> References: <b9c53237-4b1a-a140-f692-bf5837060b18@selasky.org> <1484682389.86335.166.camel@freebsd.org> <11f27a15-f9bc-8988-a17e-78aeff1745fb@selasky.org> <3558195.Ack1AKBXSB@ralph.baldwin.cx> <24593c49-b0d5-8aaf-e11b-bfef4704267e@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------A39E9900D0A639AF85AD82CA
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------A39E9900D0A639AF85AD82CA
Content-Type: text/x-patch;
name="timer_init_fix2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="timer_init_fix2.diff"
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);
}
--------------A39E9900D0A639AF85AD82CA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f675e822-afce-b666-72ca-9a6ea77209e5>