MFC r312551:

Fix for race leading to endless timer interrupts related to
configtimer().

During normal operation "state->nextcallopt" will always be less than
or equal to "state->nextcall" and checking only "state->nextcallopt"
before calling "callout_process()" is sufficient. However when
"configtimer()" is called a race might happen requiring both of these
binary times to be checked.

Short description of race:

1) A configtimer() call will reset both "state->nextcall" and
"state->nextcallopt" to the same binary time.

2) If a "callout_reset()" call happens between "configtimer()" and the
next "callout_process()" call, "state->nextcallopt" will get updated
and "state->nextcall" will remain at the current time. Refer to logic
inside cpu_new_callout().

3) getnextcpuevent() only respects "state->nextcall" and returns this
value over and over again, even if it is in the past, until "now >=
state->nextcallopt" becomes true. Then these two time variables are
corrected by a "callout_process()" call and the situation goes back to
normal.

The problem manifests itself in different ways. The common factor is
the timer process(es) consume all CPU on one or more CPU cores for a
long time, blocking other kernel processes from getting execution
time. This can be seen by very high interrupt counts as displayed by
"vmstat -i | grep timer" right after boot.

When EARLY_AP_STARTUP was enabled in r310177 the likelyhood of hitting
this bug apparently increased.

Example output from "vmstat -i" before patch:
cpu0:timer 7591 69
cpu9:timer 39031773 358089
cpu4:timer 9359 85
cpu3:timer 9100 83
cpu2:timer 9620 88

Example output from "vmstat -i" after patch:
cpu0:timer 4242 34
cpu6:timer 5531 44
cpu3:timer 6450 52
cpu1:timer 4545 36
cpu9:timer 7153 58

Before the patch cpu9 in the example above, was spinning in a loop in
order to reach 39 million interrupts just a few seconds after
bootup. After the patch the timer interrupt counts are more or less
consistent.

Discussed with: mav @
Reported by: several people
Sponsored by: Mellanox Technologies

MFC r264388 (by davide):
Define SBT_MAX.

MFC r267896 (by davide):
Improve r264388.

MFC note. The SBT_MAX definition already existed on stable/10, but without
the refinement from r267896. Also, consumers of SBT_MAX were not converted,
since r264388 was not merged properly.

Reviewed by: mav

MFC r275576: remove opensolaris cyclic code, replace with high-precision callouts

MFC 276724:
On some Intel CPUs with a P-state but not C-state invariant TSC the TSC
may also halt in C2 and not just C3 (it seems that in some cases the BIOS
advertises its C3 state as a C2 state in _CST). Just play it safe and
disable both C2 and C3 states if a user forces the use of the TSC as the
timecounter on such CPUs.

PR: 192316

MFC r278209:
Add ddb command 'show clocksource'.

MFC 264019, 264041, 264048, 264049, 264050, 264051

Add support for event timers whose clock frequency can change while running.

Apparently all ARM configs build kern_et.c, but only a few of them also
build kern_clocksource.c, un-break the build by not referencing functions in
kern_clocksource if NO_EVENTTIMERS is defined.

Add variable-frequency support to the arm mpcore eventtimer driver.

mpcore_timer: Disable the timer and clear any pending bit, then setup the
new counter register values, then restart the timer. Also re-nest the parens
properly for casting the result of converting time and frequency to a count.

MFC r259464:
Fix periodic per-CPU timers startup on boot.

MFC r275576: remove opensolaris cyclic code, replace with high-precision callouts

MFC 276724:
On some Intel CPUs with a P-state but not C-state invariant TSC the TSC
may also halt in C2 and not just C3 (it seems that in some cases the BIOS
advertises its C3 state as a C2 state in _CST). Just play it safe and
disable both C2 and C3 states if a user forces the use of the TSC as the
timecounter on such CPUs.

PR: 192316

MFC r278209:
Add ddb command 'show clocksource'.

MFC 264019, 264041, 264048, 264049, 264050, 264051

Add support for event timers whose clock frequency can change while running.

Apparently all ARM configs build kern_et.c, but only a few of them also
build kern_clocksource.c, un-break the build by not referencing functions in
kern_clocksource if NO_EVENTTIMERS is defined.

Add variable-frequency support to the arm mpcore eventtimer driver.

mpcore_timer: Disable the timer and clear any pending bit, then setup the
new counter register values, then restart the timer. Also re-nest the parens
properly for casting the result of converting time and frequency to a count.

MFC r259464:
Fix periodic per-CPU timers startup on boot.