Mark Kettenis <mark.kette...@xs4all.nl> writes:
>> From: Dave Voutila <d...@sisu.io> >> Date: Fri, 29 Jul 2022 10:51:20 -0400 >> >> 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? > > With cold boot I mean pressing the powerbutton after brining the > machine down with shutdown -hp. Warm boot is simply doing a reboot. Ah, ok. I see no difference in the TSC sync results or the selection of the timecounter (selects acpihpet0). -dv
