Linux 7.3 Will Add Per-CCD Temperature Sensors for AMD EPYC 9005

Phoronix first reported the change as part of the Linux 7.3 hardware-monitoring pull request. The kernel mailing-list record adds the important implementation detail: this is a narrowly targeted correction for EPYC Turin’s CPU model range, its CCD sensor register offset, and its higher supported CCD count. The patch was tested on an EPYC 9555P, then accepted by hardware-monitoring maintainer Guenter Roeck.

The immediate caveat is timing. Linux 7.3 is still in its merge window as of August 24, 2026; Linux 7.2 is the released mainline kernel. Administrators will not get these sensor labels merely by updating lm-sensors, Grafana, Prometheus exporters, or another dashboard. They need a kernel containing the accepted patch, whether that is an eventual Linux 7.3 release candidate, the final Linux 7.3 kernel, or a distribution backport.

The fix is larger than one new temperature label​

The k10temp driver has long exposed AMD processor thermal data through Linux’s hwmon subsystem. On supported Ryzen desktop chips, it can show individual CCD readings such as Tccd1, Tccd2, and onward alongside broader values such as Tctl and Tdie.

EPYC 9005 needed separate handling. Turin processors fall into a different Zen 5 CPU model range than desktop Ryzen parts, and their CCD temperature registers live at a different offset. The existing driver therefore did not simply lack a list of product IDs; it was looking in the wrong location for this class of per-CCD sensor data and was constrained by a lower CCD maximum.

The accepted revision changes both elements. It identifies the Zen 5 Turin model range, sets a CCD register offset of 0x1F0, and expands the driver’s maximum from 12 to 16 CCD channels. That last point deserves attention: the patch does not promise that every EPYC 9005 SKU will expose sixteen live readings. It lets the driver address up to sixteen CCDs where the processor’s configuration supports them.

That distinction makes the update more useful than a generic “EPYC temperature support” announcement. Package-level temperatures can show that a CPU is warm. Per-CCD data can show whether one chiplet is consistently warmer than its peers under a particular workload, fan curve, rack position, or cooling configuration.

Why EPYC monitoring had a blind spot​

The original patch submission described the problem plainly: Zen 5 Turin has a different model range, a different offset, and a larger maximum CCD count than desktop counterparts. The first version added four labels, from Tccd13 through Tccd16, plus the Turin-specific detection logic. The revised patch made the implementation complete by extending the driver’s readable channels and hardware-monitoring metadata to cover all sixteen.

That revision history matters because it answers a practical question left unaddressed in the short announcement: the change is not an arbitrary extension of displayed labels. The driver’s internal channel limit also had to be raised. Without that adjustment, adding label strings alone would have produced an incomplete implementation.

The kernel mailing list also records that the patch was tested on an AMD EPYC 9555P. That is meaningful validation for the code path, but it is not broad public compatibility certification for every EPYC 9005 processor, motherboard, BIOS revision, or operating-system image. The record does not identify tests on dual-socket systems, virtualized hosts, OEM platforms, or every Turin SKU.

Administrators should therefore treat the feature as upstream hardware enablement, not as a reason to retire out-of-band management monitoring. BMC telemetry and platform-specific sensors remain essential for fan, inlet-air, VRM, DIMM, and chassis diagnostics. The k10temp addition improves visibility from the host OS; it does not replace the server’s management controller.

What Linux 7.3 systems should expose​

Once a system is running a kernel that contains the patch and the k10temp module is loaded, the readings should appear through the standard Linux hardware-monitoring interface. Tools that already consume hwmon data generally do not need special support for EPYC 9005 specifically; they need to discover and retain the newly available channels.

For a direct check on a test host, administrators can start with:

sudo modprobe k10temp
sensors

On a suitably configured EPYC 9005 system, the relevant k10temp block should include its usual package or die data and may add labels from Tccd1 through the number of active, readable CCDs. A machine does not have to display all sixteen labels to be functioning correctly. The processor’s physical configuration determines how many CCDs are present and reportable.

Monitoring integrations deserve a separate validation step. Some exporters enumerate sensors dynamically, while others rely on allowlists, fixed names, or a saved inventory from an earlier kernel. A Prometheus node exporter deployment, for example, may surface the new values once its textfile or hardware-monitoring collector is enabled, but dashboards and alerts still need queries that recognize the labels. An older dashboard that only tracks Tctl will remain blind to the new granularity even after the kernel upgrade.

There is also a risk of false comparisons. A CCD sensor is not automatically a direct substitute for a package-control temperature in thermal alarm logic. Operators should first observe the readings during known workloads, establish the usual spread among chiplets, and confirm how their existing monitoring stack maps labels to CPU sockets. On multi-socket machines, sensor-device naming and discovery order can matter as much as the new driver support.

The operational value is diagnosis, not a new thermal control feature​

Nothing in the accepted patch changes EPYC power limits, Precision Boost behavior, firmware thermal policy, fan control, or Linux CPU scheduling. It adds observability. The practical result is that a workload concentrated on a particular NUMA node or group of CCDs can now be correlated with thermal variation visible inside the operating system.

That can help distinguish several otherwise similar incidents:

• A package temperature increase accompanied by one materially hotter CCD can point toward uneven workload placement, localized cooling variation, or a socket-level airflow issue.
• A broad rise across all CCDs is more consistent with ambient temperature, chassis airflow, or sustained whole-socket utilization.
• A flat host-reported CPU temperature can no longer be assumed to mean all compute chiplets are operating under the same thermal conditions.

The feature is particularly relevant to capacity planners and performance teams working with NUMA-aware applications, virtualization hosts, databases, HPC workloads, and AI inference services. Those environments may distribute work unevenly across a many-CCD server processor, and their operators often already collect CPU utilization by NUMA node. Per-CCD thermals provide a closer physical signal to compare against that logical workload placement.

Still, the kernel patch does not prove cause and effect. A hotter CCD does not by itself establish a defective processor, a bad cooler, or misconfigured scheduling. It gives administrators a more precise starting point before they escalate to BIOS analysis, BMC logs, hardware replacement, or application tuning.

Do not expect it in existing enterprise kernel streams immediately​

The mainline acceptance is the beginning of availability, not broad deployment. Linux distribution kernels often ship on schedules that do not align with upstream releases, and enterprise distributions commonly retain a long-term kernel version while selectively backporting hardware support. A system labeled with a newer distribution release can therefore still lack this change; another system on an older-looking enterprise kernel might receive it later as a vendor backport.

The practical check is the running kernel and its k10temp source, not the distribution name alone. Teams that need the visibility before their vendor adopts Linux 7.3 should ask for a supported backport rather than compile an untracked production kernel just to obtain four more sensor labels. The patch is small, but it affects low-level CPU sensor addressing, which is exactly the kind of code organizations should consume through their normal kernel support process.

For now, the tangible milestone is straightforward: EPYC 9005 hosts moving to Linux 7.3-era kernels should gain up to sixteen Tccd readings through the standard monitoring path. That closes a visibility gap that persisted even though comparable per-CCD reporting was already available on Zen 5 Ryzen desktops.