On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote: > > Scott Cheloha <scottchel...@gmail.com> writes: > > > Hi, > > > > Thanks to everyone who tested v3. > > > > Attached is v4. I would like to put this into snaps (bcc: deraadt@). > > > > If you've been following along and testing these patches, feel free to > > continue testing. If your results change from v3 to v4, please reply > > with what happened and your dmesg. > > > > I made a few small changes from v3: > > > > - Only run the sync test after failing it on TSC_DEBUG kernels. > > For example, it would be a waste of time to run the sync test > > for 62 other CPU pairs if the CPU0/CPU1 sync test failed. > > > > - Pad the tsc_test_status struct by hand. Try to keep > > tsc_test_status.val onto its own cache line and try to prevent one > > instance of the struct from sharing a cache line with another > > instance. > > > > I am looking for OKs. > > > > Assuming the results from snaps testing aren't catastrophic, and this > > version is OK'd, I hope to commit this after a couple weeks in snaps. > > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop > running the latest kernel from snaps.
Define "breaking". The code detects TSC desync and marks the timecounter non-monotonic. So it uses the i8254 instead. This is the intended behavior of the patch. The latest news on the desync we're seeing on certain Ryzen CPUs is that an engineer at AMD has said it might be a bug in AGESA and that if/when BIOS vendors pull in a fix from AMD and distribute it to customers it may solve the problem: https://bugzilla.kernel.org/show_bug.cgi?id=216146#c7 -- Or do you mean "breaking" in some other way?
