[bug]: Metrics temperature gauge reports the hottest sensor in the box, not the CPU

[helix-nine]

What happens

The Metrics tab's Temperature gauge reports the hottest temp1_input across every chip sensors -j returns. On boards where a non-CPU sensor idles hot (very common for Intel PCH virtual sensors), the gauge shows a number that has nothing to do with how hot the machine actually is.

Reported by @maniqui in #3336 on an Asus Chromebox CN62 running 0.4.0-beta: the gauge read ~88 °C idle and ~115 °C during IBD, which read as an emergency and cost him a round of thermal troubleshooting. Actual CPU at the same moment:

coretemp-isa-0000
Package id 0:  +36.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +36.0°C
Core 1:        +35.0°C

acpitz-acpi-0
temp1:        +37.0°C

pch_wildcat_point-virtual-0
temp1:        +88.5°C     <-- this is what the gauge shows

So the box was at 36 °C and StartOS said 88 °C.

Why

get_temp() in shared-libs/crates/start-core/src/system/mod.rs (~L916) flattens every chip from sensors -j, keeps each chip's temp1_input, and reduces with f64::max:

.filter_map(|(k, v)| {
    // we have seen so far that `temp1` is always a composite reading of some sort, so we should just use that for each chip
    if k.trim() == "temp1_input" { v.as_f64() } else { None }
})
.reduce(f64::max)

The temp1 heuristic is about picking the composite reading within a chip, which is fine. The problem is the max across chips: any single hot-running or miscalibrated sensor wins and becomes "the" temperature. pch_wildcat_point is a well-known offender (Intel PCH sensors idle hot and are not calibrated to be comparable to core temps).

That value flows straight through MetricsGeneral.temperature to the single gauge headed Temperature in projects/start-os/web/ui/src/app/routes/portal/routes/metrics/metrics.component.ts (L27-28), so the user sees one unlabeled number with no indication of which sensor produced it.

Related history: #1946 and #2207, which is where the move to lm-sensors came from.

The actual design question

Worth settling before anyone writes a patch, because it decides the fix:

Is that gauge meant to be "CPU temperature" or "hottest component in the box"?

• If CPU — prefer a known CPU chip and only fall back to the current max-across-all when none is recognized. Something like coretemp-* (Intel), k10temp-* / zenpower-* (AMD), cpu_thermal-* (Pi), else today's behavior. This is conservative: it only changes what's displayed when a recognized CPU sensor exists, and in that case the CPU reading is unambiguously the better answer. VMs still report N/A.
• If hottest component — then the code is working as designed and the bug is presentational: the gauge needs to name the sensor it's showing, and probably needs per-chip thresholds, since 88 °C on a PCH and 88 °C on a CPU package mean completely different things.

I lean toward the first, but this is a product call rather than an obvious defect, so flagging rather than sending a patch. Happy to write whichever one you want.

Scope note

Filed out of #3336, which was closed as a hardware issue. The NVMe/read-only half of that report is genuinely hardware; this temperature item is separate, is on the StartOS side, and would otherwise be lost in a closed thread.

[dr-bonez]

@MattDHill this is a product decision I want your call on. The current behavior is as-designed, but not ideal. But a dashboard showing the temp of every component might be TMI, and also defining the "safe" range of every possible component a user could have is intractable. Best we could do is surface the existing high/crit settings if present, but I suspect that info will be absent on most components.

[helix-nine]

@dr-bonez Your suspicion about high/crit is right, and it's stronger than "absent on most components" — for the sensors that cause this bug it's structurally guaranteed absent, on every kernel version. That does rule one of the two options out, so posting the measurement before anyone spends design time on it.

Chips backed by a thermal zone can never expose a threshold

thermal_hwmon gates the temp1_crit attribute on the driver's own ops callback, not on the thermal core's helper that falls back to scanning trip points:

static bool thermal_zone_crit_temp_valid(struct thermal_zone_device *tz)
{
	int temp;
	return tz->ops.get_crit_temp && !tz->ops.get_crit_temp(tz, &temp);
}

Exactly one driver in the entire tree implements .get_crit_temp — drivers/platform/x86/acerhdf.c, an Acer Aspire One fan-control driver. Everything else that mentions it is a consumer of thermal_zone_get_crit_temp(). I grepped all of drivers/ and include/ on current mainline; the gate is byte-identical in 6.1, 6.6 and 6.12, so this isn't version-sensitive. thermal_hwmon also only ever creates temp1_input and temp1_crit, so there is no temp1_max ("high") on that path at all, and no temp1_label either.

So every *-virtual-* chip reports a bare number and nothing else. That covers acpitz, cpu_thermal on the Pi, and pch_wildcat_point.

The PCH case is a nice illustration of why the fallback matters: intel_pch_thermal does register a THERMAL_TRIP_CRITICAL from the WPT_CTT register, so the hardware threshold exists — it just never reaches userspace, because the driver doesn't implement the callback hwmon checks. Which matches @maniqui's paste exactly: 88.5 °C with no high/crit next to it.

Real hwmon drivers do carry thresholds

coretemp builds temp1_label, temp1_crit_alarm, temp1_input, temp1_crit, temp1_max, and the package sensor is always index 1:

/* The Pkgtemp will always show up as temp1_*, if available */
int attr_no = is_pkg_temp_data(tdata) ? 1 : tdata->cpu_core_id + 2;

Same for k10temp, drivetemp, nvme, nct6775. Worth noting this also confirms the existing "temp1 is the composite reading" heuristic is correct — for coretemp it lands on the package, which is the right number.

What this means for the call

The split is clean, and it's not a coincidence: the chips with thresholds are the ones with a real driver that knows what it's measuring, and the chips without are generic thermal zones. "Surface the existing high/crit if present" is unavailable for precisely the sensors that produce the bad reading — the 88.5 °C PCH value can't be annotated, and on a Pi cpu_thermal is a thermal zone too, so that whole platform's gauge would carry no context. Per-chip thresholds would have to come from a table we maintain by hand, which is the intractable thing you're describing.

Preferring a recognized CPU chip gets the threshold for free, since coretemp/k10temp are exactly the drivers that publish crit (Tjmax) and max, plus a temp1_label if the gauge ever wants to name what it's showing.

To be clear I'm not trying to make the product call for you — "CPU temp" vs "hottest component" is still @MattDHill's, and I'll write either. I just don't think the threshold-annotation mitigation is on the table.

Happy to send the CPU-preference patch on a word; it's a small change to get_temp() that only alters behavior when a recognized CPU chip is present, so VMs and unrecognized boards keep today's reading.

Verification: thermal_hwmon.c / thermal_core.c / intel_pch_thermal.c / coretemp.c as of torvalds/linux at v7.2-rc7, cross-checked against the v6.1, v6.6 and v6.12 tags.