TSC timecounter [was Re: sdmmc_mem_enable failed with error 60]

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Wed, Apr 08, 2020 at 08:49:01AM -0400, Greg Troxel wrote:
> Patrick Welche <prlw1%cam.ac.uk@localhost> writes:
> 
> > Having seen TSC related commits, I tried TSC again, and noticed that
> > I could read/write SD cards again, and irritating pckb command timeouts
> > stopped happening. This laptop seems stable apart from the incorrect
> > time.
> 
> Does the time work ok with TSC, with the new commits?  Basically there
> was a bug in estimating TSC rate, which I think was a multiprocessing
> hazard.
> 
> I have a system where TSC should be 2.8G, and it was being measured at
> boot at 3.9G sometimes (and sometimes 2.8G).   I haven't tried to
> backport the patches to 8 and test, but my guess is that I'll have the
> right TSC value and timekeeping with TSC will be ok.

No, unfortunately it is still off after the change, e.g., running a
kernel from today's source:

kern.timecounter.choice = TSC(q=3000, f=8826798620 Hz) clockinterrupt(q=0, f=100 Hz) hpet0(q=2000, f=24000000 Hz) ACPI-Fast(q=1000, f=3579545 Hz) lapic(q=-100, f=100316472 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-1000000, f=1000000 Hz)
kern.timecounter.hardware = TSC

$ uptime
 1:56PM  up 3 mins, 4 users, load averages: 0.02, 0.02, 0.00
quark

and in those 3 minutes I have apparently been able to load email, check
on CVS etc. Much more like a quarter of an hour...


Cheers,

Patrick