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

Reply via email to