Description
On Apple M5 Pro chips, CPU frequency detection is broken. P-Core frequency returns an incorrect value (4.6 MHz instead of ~4.6 GHz), E-Core frequency returns 0, and GHz functions return 0 due to integer truncation.
The IOKit properties voltage-states5-sram (P-core) and voltage-states1-sram (E-core) behave differently on M5 Pro compared to M1-M3 chips.
Environment
Reproduction
package main
import (
"fmt"
m1cpu "github.com/shoenig/go-m1cpu"
)
func main() {
fmt.Println("P-Core Hz:", m1cpu.PCoreHz())
fmt.Println("E-Core Hz:", m1cpu.ECoreHz())
fmt.Println("P-Core GHz:", m1cpu.PCoreGHz())
fmt.Println("E-Core GHz:", m1cpu.ECoreGHz())
fmt.Println("Model:", m1cpu.ModelName())
fmt.Println("P-Cores:", m1cpu.PCoreCount())
fmt.Println("E-Cores:", m1cpu.ECoreCount())
}Actual output (M5 Pro, with PR #29 applied)
P-Core Hz: 4608000
E-Core Hz: 0
P-Core GHz: 0
E-Core GHz: 0
Model: Apple M5 Pro
P-Cores: 6
E-Cores: 12
Expected output
P-Core Hz: ~4600000000
E-Core Hz: ~2800000000
P-Core GHz: ~4.6
E-Core GHz: ~2.8
Model: Apple M5 Pro
P-Cores: 6
E-Cores: 12
Analysis
- P-Core:
voltage-states5-sram returns a raw value that getFrequency() parses as 4608. The toHz() function detects M5 (gen >= 4) and multiplies by 1000, yielding 4608000 (~4.6 MHz). The actual frequency is ~4.6 GHz, so the raw value or the multiplier is wrong.
- E-Core:
voltage-states1-sram likely doesn't exist on M5 Pro — IORegistryEntryCreateCFProperty() returns NULL, so getFrequency() returns 0.
- GHz functions:
PCoreGHz() returns 0 because it does integer division: 4608000 / 1000000000 = 0.
The IOKit property names or data format may have changed in the M5 generation. Core counts (hw.perflevel0.physicalcpu, hw.perflevel1.physicalcpu) and cache sizes work correctly via sysctl.
A possible fallback for frequency could be sysctl hw.cpufrequency_max or discovering the correct IOKit properties for M5.
Impact
This affects HashiCorp Nomad, which uses go-m1cpu for CPU fingerprinting. With incorrect/zero MHz reported, Nomad nodes appear to have insufficient CPU capacity and jobs stay in pending state (hashicorp/nomad#27684).
Related
Description
On Apple M5 Pro chips, CPU frequency detection is broken. P-Core frequency returns an incorrect value (4.6 MHz instead of ~4.6 GHz), E-Core frequency returns 0, and GHz functions return 0 due to integer truncation.
The IOKit properties
voltage-states5-sram(P-core) andvoltage-states1-sram(E-core) behave differently on M5 Pro compared to M1-M3 chips.Environment
Reproduction
Actual output (M5 Pro, with PR #29 applied)
Expected output
Analysis
voltage-states5-sramreturns a raw value thatgetFrequency()parses as4608. ThetoHz()function detects M5 (gen >= 4) and multiplies by 1000, yielding4608000(~4.6 MHz). The actual frequency is ~4.6 GHz, so the raw value or the multiplier is wrong.voltage-states1-sramlikely doesn't exist on M5 Pro —IORegistryEntryCreateCFProperty()returns NULL, sogetFrequency()returns 0.PCoreGHz()returns 0 because it does integer division:4608000 / 1000000000 = 0.The IOKit property names or data format may have changed in the M5 generation. Core counts (
hw.perflevel0.physicalcpu,hw.perflevel1.physicalcpu) and cache sizes work correctly via sysctl.A possible fallback for frequency could be
sysctl hw.cpufrequency_maxor discovering the correct IOKit properties for M5.Impact
This affects HashiCorp Nomad, which uses
go-m1cpufor CPU fingerprinting. With incorrect/zero MHz reported, Nomad nodes appear to have insufficient CPU capacity and jobs stay inpendingstate (hashicorp/nomad#27684).Related
CFRelease(NULL)crash on M5 but does not address frequency detection