> On Jul 6, 2022, at 10:04 AM, Christian Weisgerber <na...@mips.inka.de> wrote:
>
> Scott Cheloha:
>
>>> kern.timecounter.tick=1
>>> kern.timecounter.timestepwarnings=0
>>> kern.timecounter.hardware=i8254
>>> kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>>
>> This is expected behavior with the patch.
>>
>> cpu0's TSC is way out of sync with every
>> other CPU's TSC, so the TSC is marked
>> as a bad timecounter and a different one is
>> chosen.
>
> Shouldn't it pick acpihpet0 then?
It depends on the order the timecounters are installed.
If acpihpet0 is already installed before we degrade the
TSC's .quality value then the timecounter subsystem won't
switch to it when we install the next counter because it
assumes .quality values cannot change on the fly (a
reasonable assumption).
We don't yet have a tc_detach(9) function that uninstalls
a timecounter cleanly and chooses the next best counter
available.
This is something I want to add in a future patch. FreeBSD
has something similar. It may be called "tc_ban", iirc.
The alternative is to wait until we've tested synchronization
for every CPU before calling tc_init(9). This approach is
more annoying, though, as it requires additional state. We
would also still have the same problem when we resume from
suspend.
The dream is to be able to do something like this during the
sync test:
if (tsc_sync_test_failed) {
tc_detach(&tsc_timecounter);
tsc_timecounter.quality = -2000;
tc_init(&tsc_timecounter);
}
When we call tc_detach(9) the timecounter code would pick
the next best counter automagically.
