Public bug reported:
On a Lenovo Legion 5 16IAX10 (Core Ultra 9 275HX, Arrow Lake-HX), thermald in
its
default adaptive mode logs "Unable to read odvpNNNN" at error priority on every
poll,
continuously, for as long as it runs.
Measured on this machine: 529,567 such lines between 2026-10-06 07:59:26 and
2026-10-07 18:38:29 (34 h 39 min of uptime), about 4.2 lines per second. With
the
journal capped at 500 MB, these messages filled it in under two days and pushed
out other logs.
The firmware exposes six ODVP variables:
/sys/bus/platform/devices/INTC1042:00/odvp0 ... odvp5
thermald asks for indexes 8198 to 8210 (0x2006 to 0x2012), which do not
exist:
thermald[1697]: Unable to read odvp8209
thermald[1697]: Unable to read odvp8206
thermald[1697]: Unable to read odvp8210
thermald[1697]: Unable to read odvp8207
thermald[1697]: Unable to read odvp8199
thermald[1697]: Unable to read odvp8200
thermald[1697]: Unable to read odvp8198
These are not ODVP indexes. They are condition IDs in the 0x2000 range, which
Intel
DPTF defines as software-OEM ("SwOem") conditions, set at runtime by OEM
software on
Windows. thermald 2.5.11 treats them as ODVP variable numbers and tries to read
odvp<ID> from sysfs on every poll.
[ Fix ]
Fixed upstream in thermald 2.5.13:
commit a4f8d84b (2026-08-07)
"adaptive: Stop mapping SwOem conditions to ODVP variables"
https://github.com/intel/thermal_daemon
The change adds OEM_CONDITION_BASE_ID (0x1000), SW_OEM_CONDITION_BASE_ID
(0x2000)
and PARTICIPANT_CONDITION_BASE_ID (0x10000), and makes conditions in the SwOem
range
never match instead of being read as ODVP variables. The upstream code comment
states
the outcome is the same as before, "without the per-poll odvpN read errors".
I verified by reading the source that this change is present in v2.5.13 and
absent
from v2.5.11 and v2.5.12. I have not run 2.5.13 on this machine.
Request: backport this commit to thermald in resolute (26.04), or update
resolute to
2.5.13. The development series currently has 2.5.12, which also lacks the fix.
[ Test Plan ]
On affected hardware (Arrow Lake-HX Lenovo with SwOem conditions in its DPTF
tables):
1. Start thermald with the packaged unit (thermald --systemd --dbus-enable
--adaptive).
2. Run: journalctl -b -u thermald | grep -c "Unable to read odvp"
3. Before the fix: the count grows by roughly 4 per second.
After the fix: the count stays at 0.
4. Confirm thermald still starts and stays active.
[ Where problems could occur ]
The change only affects how adaptive-mode conditions in the SwOem ID range are
evaluated. Per upstream, condition sets using them never matched before and
never
match after, so thermal behavior should be unchanged. A regression would most
plausibly show up as a different adaptive target being selected on machines
whose
tables use IDs near the new range boundaries.
[ System ]
Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic
thermald 2.5.11-0ubuntu1.1
Lenovo Legion 5 16IAX10 (product 83NX), BIOS Q6CN79WW (2026-04-23)
Intel Core Ultra 9 275HX
ExecStart=/usr/sbin/thermald --systemd --dbus-enable --adaptive
[ Workaround ]
sudo systemctl disable --now thermald
On this machine, a 2-minute all-core load gave the same package temperature (56
C)
and fan speed with thermald running and stopped.
** Affects: thermald (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2169913
Title:
thermald 2.5.11 floods the journal with "Unable to read odvpNNNN" on
Arrow Lake-HX (Lenovo Legion 5 16IAX10): SwOem conditions misread as
ODVP variables; fixed upstream in 2.5.13
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/2169913/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
