which now validates the value in the _CRT element for the thermal zone, and ignores any thermal zones where it is invalid.
If I’m reading the DSDT correctly, the _HOT threshold is reported as 0x1218 (463.2 degrees) and the _CRT threshold is 0x12E0 (483.2 degrees). Linux ignores any threshold above 448 degrees as implausibly high.
I’m not sure how to report firmware bugs like this, but can the ACPI tables be fixed in a future firmware update so that Linux continues to report thermal information?
I filed 218652 – acpitz sensors regression on Linux 6.7+ on Framework 16 upstream for this. Still, it seems like both sides are buggy - even if they restore the missing sensors, without valid thresholds, Linux can’t suspend itself automatically when the system is overheating.
I agree with you based on what you’ve said above. You should file a report with framework support so they can get the bios side fixed in a future update.
Looks like your ticket is waiting on you to provide requested logs. From there, the ticket is then escalated and if need be, will be sent to engineering.
It looks like Kernel 6.9 will be getting a fix that will allow the thermal zones to register despite the bogus trip values. However, that does not eliminate the need for Framework to put valid thermal zone data in the ACPI tables for the various operations that may utilize the trip values.