Mark Kettenis <mark.kette...@xs4all.nl> writes:
>> From: Dave Voutila <d...@sisu.io> >> Date: Fri, 29 Jul 2022 10:10:01 -0400 >> >> Scott Cheloha <scottchel...@gmail.com> writes: >> >> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote: >> >> >> >> Stuart Henderson <s...@spacehopper.org> writes: >> >> >> >> > On 2022/07/28 12:57, Scott Cheloha wrote: >> >> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote: >> >> >> > >> >> >> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop >> >> >> > running the latest kernel from snaps. >> >> >> >> >> >> Define "breaking". >> >> > >> >> > That's clear from the output: >> >> > >> >> > : On 2022/07/28 07:55, Dave Voutila wrote: >> >> > : > $ sysctl -a | grep tsc >> >> > : > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) >> >> > : > acpitimer0(1000) >> >> > : > machdep.tscfreq=2096064730 >> >> > : > machdep.invarianttsc=1 >> >> > : > >> >> > : > $ sysctl kern.timecounter >> >> > : > kern.timecounter.tick=1 >> >> > : > kern.timecounter.timestepwarnings=0 >> >> > : > kern.timecounter.hardware=i8254 >> >> > : > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) >> >> > : > acpitimer0(1000) >> >> > >> >> >> The code detects TSC desync and marks the timecounter non-monotonic. >> >> > >> >> > That's good (and I think as would have happened before) >> >> > >> >> >> So it uses the i8254 instead. >> >> > >> >> > But that's not so good, there are higher prio timecounters available, >> >> > acpihpet0 and acpitimer0, which would be better choices than i8254. >> >> >> >> Exactly my point. Thanks Stuart. >> > >> > Okay, please try this patch on the machine in question. >> >> That fixes the selection on my x13 gen1; it's choosing acpihpet0 now. No >> issue with suspend/resume cycles either. >> >> Also tested the patch on my dual-socket Xeon machine and it looks to >> still be properly synchronizing and selecting tsc as with the previous >> diff & snapshot kernel. >> >> Is there any special consideration for unhiberate? I can't tell if/when >> it is checking the TSCs across the cpus. > > Based on the link Scott posted yesterday, it would be interesting to > see if there is a difference between a cold boot and a warm boot. > Does it pick the TSC after a cold boot? And if so, what happens if > you hibernate after a warm boot (with the HPET as source) and > unhibernate after a cold boot. > Hmm...what's the best way to force cold/warm on an x13 Ryzen system? Do I need to do this from UEFI? -dv