Bad relative frequency values when resuming from STR

[cyring]

• Issue started appearing with my Zen2/Matisse
• Highest frequency ratio is reaching 18446744073027
• Converted to a signed value, this ratio sounds like an overflow
• Press the UI shortcut [*] will reset that limit; but oftenly for a short time

[cyring]

• With my Intel Xeon/Westmere, the bug is not reproductible

• Observe that Turbo is not restored from STR

Investigations

• Matisse PMU counters are not properly reprogrammed after STR
• Race condition among Daemon aggregations
• Fresh boot use-case vs STR use-case

[cyring]

Race condition among Daemon aggregations

• When notified of a Resume action, the Daemon Manager thread is resetting the per-cpu limits, including the lowest and highest relatives frequencies: https://github.com/cyring/CoreFreq/blob/5127cc858078fbac640a443bfa9d4dabd552c5e0/corefreqd.c#L6669
• In parallel the per-cpu threads are collecting and computing their own limits: https://github.com/cyring/CoreFreq/blob/5127cc858078fbac640a443bfa9d4dabd552c5e0/corefreqd.c#L1126
• The Limits data is not protected by the Flip-Flop mechanism

Commenting out

• The reset loop is commented out: https://github.com/cyring/CoreFreq/blob/5127cc858078fbac640a443bfa9d4dabd552c5e0/corefreqd.c#L6665
• Issue is still present. The wrong value is indeed assigned to the computed relative frequency. The highest limit being a consequence of the former value. https://github.com/cyring/CoreFreq/blob/5127cc858078fbac640a443bfa9d4dabd552c5e0/corefreqd.c#L1118

[cyring]

Fresh boot use-case vs STR use-case

• The issue is not encountered when the Ryzen is freshly booted; only during STR.

• Let's change the use-case:

  1. Fresh boot the PC
  2. When Linux is started up, immediately trigger the Suspend To Ram systemctl suspend or any GUI Suspend button
  3. Wake up PC from STR
  4. Now start CoreFreq and check the issue ?

• Here we are: issue is present !!!

• Programming the PMU right after a S3 STR is problematic

[cyring]

Differed

[cyring]

• Read-Only Max Performance Frequency and Actual Performance Clock Count MSR are the source of the issue.

  rdmsr -aX 0xc00000e7
  43BD09640
  FFFFFFFC4D6FD38C
  FFFFFFFC62323567
  FFFFFFFBA3B8DD2F
  FFFFFFFD6BD6F61A
  ...

  rdmsr -aX 0xc00000e8
  330303E31
  28AAE332
  FFFFFFF9F152C3F1
  7D303A01
  ...

• Those registers can be employed when compiling as bellow:

  make MSR_CORE_PERF_UCC=MSR_AMD_F17H_APERF MSR_CORE_PERF_URC=MSR_AMD_F17H_MPERF clean all

• Start CoreFreq , next trigger Suspend to RAM
• Back from STR, upper 32-bits of counters are stuck to 0xFFFFFFF
• MPerfReadOnly and APerfReadOnly are read only thus they can not be rewritten to a reset value.