| 2016-02-08 10:16:52 |
Colin Ian King |
bug |
|
|
added bug |
| 2016-02-08 10:16:58 |
Colin Ian King |
thermald (Ubuntu): status |
New |
In Progress |
|
| 2016-02-08 10:17:00 |
Colin Ian King |
thermald (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-02-08 10:17:02 |
Colin Ian King |
thermald (Ubuntu): assignee |
|
Colin Ian King (colin-king) |
|
| 2016-02-08 11:46:33 |
Colin Ian King |
bug |
|
|
added subscriber Srinivas Pandruvada |
| 2016-02-08 16:51:54 |
Jamie Strandboge |
bug |
|
|
added subscriber Jamie Strandboge |
| 2016-02-16 15:48:34 |
Chris J Arges |
bug |
|
|
added subscriber Chris J Arges |
| 2016-02-18 11:00:32 |
Colin Ian King |
thermald (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2016-02-18 11:00:35 |
Colin Ian King |
thermald (Ubuntu): importance |
Medium |
High |
|
| 2016-02-18 18:55:20 |
Colin Ian King |
thermald (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-03-08 09:01:39 |
Dr4K4n |
bug |
|
|
added subscriber Dr4K4n |
| 2016-03-10 06:55:11 |
Sebastian |
bug |
|
|
added subscriber Sebastian |
| 2016-04-11 15:49:33 |
Colin Ian King |
nominated for series |
|
Ubuntu Wily |
|
| 2016-04-11 15:49:33 |
Colin Ian King |
bug task added |
|
thermald (Ubuntu Wily) |
|
| 2016-04-11 15:49:33 |
Colin Ian King |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-04-11 15:49:33 |
Colin Ian King |
bug task added |
|
thermald (Ubuntu Trusty) |
|
| 2016-04-11 15:49:40 |
Colin Ian King |
thermald (Ubuntu Trusty): assignee |
|
Colin Ian King (colin-king) |
|
| 2016-04-11 15:49:42 |
Colin Ian King |
thermald (Ubuntu Wily): assignee |
|
Colin Ian King (colin-king) |
|
| 2016-04-11 15:49:44 |
Colin Ian King |
thermald (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2016-04-11 15:49:45 |
Colin Ian King |
thermald (Ubuntu Wily): importance |
Undecided |
High |
|
| 2016-04-11 15:49:49 |
Colin Ian King |
thermald (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-04-11 15:49:52 |
Colin Ian King |
thermald (Ubuntu Wily): status |
New |
In Progress |
|
| 2016-04-11 15:58:54 |
Colin Ian King |
description |
When thermald updates /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw the kernel is emitting the following message:
[38458.753468] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38637.993447] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38674.154336] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38691.500619] powercap intel-rapl:0: package locked by BIOS, monitoring only
This message comes from set_power_limit() in drivers/powercap/intel_rapl.c because the domain is locked by the BIOS. Writing to this interface fails with an error:
open("/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw", O_WRONLY) = 3
write(3, "35000000", 8) = -1 ENODATA (No data available)
so in theory thermald should be seeing this failed write and handling it appropriately rather.
cthd_sysfs_cdev_rapl::set_curr_state() and cthd_sysfs_cdev_rapl::set_curr_state_raw() in src/thd_cdev_rapl.cpp perform the update and they do check that the sysfs write fails:
if (cdev_sysfs.write(tc_state_dev.str(), state_str.str()) < 0)
curr_state = (state == 0) ? 0 : max_state;
however, I believe they should check errno for the failed write and disable the rapl interface if we get -ENODATA on this interface to avoid repeated failures and hence repeated spamming of kernel messages |
[SRU Justification][Trusty][Wily]
thermald is triggering the kernel to SPAM the kernel log with frequent "package locked by BIOS, monitoring only" messages.
[Fix]
This issue is fixed with the following upstream commits:
f1a77c5f3b936ba8a7a63d587a803641974f8e62 ("thd_cdev_rapl: stop writing to sysfs if the write fails (LP: #1543046)")
833245725494eb26a1c61ca6f1a9db90599ae71b ("Initialize bios_locked to false")
These two fixes have been shown to work on Xenial and apply cleanly to Trusty and Wily versions of thermald. The risk of regression is low since these fixes add extra sanity checking to the code rather than completely new functionality plus they are upstream commits that have been available Xenial for some time now.
[Testcase]
Run on a system that reads /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw where the BIOS has this feature locked and the kernel emits this message every time thermald accesses this /sys file.
With the fix, this message only appears once, and no more spamming occurs thereafter.
[Regression Potential]
Minimal. The fixes are upstream and have been tested in Xenial for quite a while. The fixes patch cleanly to Trusty and Wily and result in the same upstream code, so the code paths are identical to that of Xenial's thermald.
----------------------------------------
When thermald updates /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw the kernel is emitting the following message:
[38458.753468] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38637.993447] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38674.154336] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38691.500619] powercap intel-rapl:0: package locked by BIOS, monitoring only
This message comes from set_power_limit() in drivers/powercap/intel_rapl.c because the domain is locked by the BIOS. Writing to this interface fails with an error:
open("/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw", O_WRONLY) = 3
write(3, "35000000", 8) = -1 ENODATA (No data available)
so in theory thermald should be seeing this failed write and handling it appropriately rather.
cthd_sysfs_cdev_rapl::set_curr_state() and cthd_sysfs_cdev_rapl::set_curr_state_raw() in src/thd_cdev_rapl.cpp perform the update and they do check that the sysfs write fails:
if (cdev_sysfs.write(tc_state_dev.str(), state_str.str()) < 0)
curr_state = (state == 0) ? 0 : max_state;
however, I believe they should check errno for the failed write and disable the rapl interface if we get -ENODATA on this interface to avoid repeated failures and hence repeated spamming of kernel messages |
|
| 2016-04-11 16:00:17 |
Colin Ian King |
description |
[SRU Justification][Trusty][Wily]
thermald is triggering the kernel to SPAM the kernel log with frequent "package locked by BIOS, monitoring only" messages.
[Fix]
This issue is fixed with the following upstream commits:
f1a77c5f3b936ba8a7a63d587a803641974f8e62 ("thd_cdev_rapl: stop writing to sysfs if the write fails (LP: #1543046)")
833245725494eb26a1c61ca6f1a9db90599ae71b ("Initialize bios_locked to false")
These two fixes have been shown to work on Xenial and apply cleanly to Trusty and Wily versions of thermald. The risk of regression is low since these fixes add extra sanity checking to the code rather than completely new functionality plus they are upstream commits that have been available Xenial for some time now.
[Testcase]
Run on a system that reads /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw where the BIOS has this feature locked and the kernel emits this message every time thermald accesses this /sys file.
With the fix, this message only appears once, and no more spamming occurs thereafter.
[Regression Potential]
Minimal. The fixes are upstream and have been tested in Xenial for quite a while. The fixes patch cleanly to Trusty and Wily and result in the same upstream code, so the code paths are identical to that of Xenial's thermald.
----------------------------------------
When thermald updates /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw the kernel is emitting the following message:
[38458.753468] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38637.993447] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38674.154336] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38691.500619] powercap intel-rapl:0: package locked by BIOS, monitoring only
This message comes from set_power_limit() in drivers/powercap/intel_rapl.c because the domain is locked by the BIOS. Writing to this interface fails with an error:
open("/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw", O_WRONLY) = 3
write(3, "35000000", 8) = -1 ENODATA (No data available)
so in theory thermald should be seeing this failed write and handling it appropriately rather.
cthd_sysfs_cdev_rapl::set_curr_state() and cthd_sysfs_cdev_rapl::set_curr_state_raw() in src/thd_cdev_rapl.cpp perform the update and they do check that the sysfs write fails:
if (cdev_sysfs.write(tc_state_dev.str(), state_str.str()) < 0)
curr_state = (state == 0) ? 0 : max_state;
however, I believe they should check errno for the failed write and disable the rapl interface if we get -ENODATA on this interface to avoid repeated failures and hence repeated spamming of kernel messages |
[SRU Justification][Trusty][Wily]
thermald is triggering the kernel to SPAM the kernel log with frequent "package locked by BIOS, monitoring only" messages.
[Fix]
This issue is fixed with the following upstream commits:
f1a77c5f3b936ba8a7a63d587a803641974f8e62 ("thd_cdev_rapl: stop writing to sysfs if the write fails (LP: #1543046)")
833245725494eb26a1c61ca6f1a9db90599ae71b ("Initialize bios_locked to false")
These two fixes have been shown to work on Xenial and apply cleanly to Trusty and Wily versions of thermald. The risk of regression is low since these fixes add extra sanity checking to the code rather than completely new functionality plus they are upstream commits that have been available Xenial for some time now.
[Testcase]
Run on a system that reads /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw where the BIOS has this feature locked and the kernel emits this message every time thermald accesses this /sys file.
With the fix, this message only appears once, and no more spamming occurs thereafter.
[Regression Potential]
Minimal. The fixes are upstream and have been tested in Xenial for quite a while. The fixes patch cleanly to Trusty and Wily and result in the same upstream code, so the code paths are identical to that of Xenial's thermald.
----------------------------------------
When thermald updates /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw the kernel is emitting the following message:
[38458.753468] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38637.993447] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38674.154336] powercap intel-rapl:0: package locked by BIOS, monitoring only
[38691.500619] powercap intel-rapl:0: package locked by BIOS, monitoring only
This message comes from set_power_limit() in drivers/powercap/intel_rapl.c because the domain is locked by the BIOS. Writing to this interface fails with an error:
open("/sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw", O_WRONLY) = 3
write(3, "35000000", 8) = -1 ENODATA (No data available)
so in theory thermald should be seeing this failed write and handling it appropriately rather.
cthd_sysfs_cdev_rapl::set_curr_state() and cthd_sysfs_cdev_rapl::set_curr_state_raw() in src/thd_cdev_rapl.cpp perform the update and they do check that the sysfs write fails:
if (cdev_sysfs.write(tc_state_dev.str(), state_str.str()) < 0)
curr_state = (state == 0) ? 0 : max_state;
however, I believe they should check errno for the failed write and disable the rapl interface if we get -ENODATA on this interface to avoid repeated failures and hence repeated spamming of kernel messages |
|
| 2016-04-11 16:06:55 |
Colin Ian King |
bug |
|
|
added subscriber Canonical Kernel SRU Team |
| 2016-04-11 16:07:06 |
Dr4K4n |
removed subscriber Dr4K4n |
|
|
|
| 2016-04-14 20:41:58 |
Brian Murray |
thermald (Ubuntu Wily): status |
In Progress |
Fix Committed |
|
| 2016-04-14 20:42:00 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-04-14 20:42:02 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2016-04-14 20:42:15 |
Brian Murray |
tags |
|
verification-needed |
|
| 2016-04-14 20:43:35 |
Brian Murray |
thermald (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2016-04-18 08:50:16 |
Martin Ekendahl |
tags |
verification-needed |
verification-failed |
|
| 2016-04-18 16:32:15 |
Martin Ekendahl |
bug |
|
|
added subscriber Martin Ekendahl |
| 2016-04-22 18:53:12 |
Colin Ian King |
tags |
verification-failed |
verification-done |
|
| 2016-04-26 09:12:23 |
Colin Ian King |
tags |
verification-done |
verification-needed |
|
| 2016-05-20 16:39:44 |
Colin Ian King |
tags |
verification-needed |
verification-done-trusty |
|
| 2016-05-26 12:03:50 |
Launchpad Janitor |
thermald (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2016-05-26 12:03:55 |
Chris J Arges |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-05-26 12:05:18 |
Launchpad Janitor |
thermald (Ubuntu Wily): status |
Fix Committed |
Fix Released |
|
| 2016-06-14 00:14:53 |
William G. Comnisky |
bug |
|
|
added subscriber William G. Comnisky |
| 2016-07-08 15:30:36 |
Colin Ian King |
thermald (Ubuntu Wily): status |
Fix Released |
In Progress |
|
| 2016-07-11 08:39:50 |
Andy Whitcroft |
thermald (Ubuntu Wily): status |
In Progress |
Fix Committed |
|
| 2016-07-11 08:39:53 |
Andy Whitcroft |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-07-11 08:40:01 |
Andy Whitcroft |
tags |
verification-done-trusty |
verification-done-trusty verification-needed |
|
| 2016-07-11 08:44:56 |
Colin Ian King |
tags |
verification-done-trusty verification-needed |
verification-done verification-done-trusty |
|
| 2016-07-19 19:27:06 |
Launchpad Janitor |
thermald (Ubuntu Wily): status |
Fix Committed |
Fix Released |
|
