Bug 1719160

Summary:	tuned: ERROR in logs when balanced profile is used. tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded
Product:	Red Hat Enterprise Linux 7	Reporter:	Robin Hack <rhack>
Component:	tuned	Assignee:	Jaroslav Škarvada <jskarvad>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	low	Docs Contact:	Marie Hornickova <mdolezel>
Priority:	low
Version:	7.7	CC:	jeder, jskarvad, olysonek, thozza
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	.Harmless error messages occur when the `balanced` Tuned profile is used The `balanced` Tuned profile has been changed in the way that the `cpufreq_conservative` kernel module loads when this profile is applied. However, `cpufreq_conservative` is built-in in the kernel, and it is not available as a module. Consequently, when the `balanced` profile is used, the following error messages occasionally appear in `/var/log/tuned/tuned.log` file: ---- tuned.utils.commands: Executing modinfo error: modinfo: ERROR: Module cpufreq_conservative not found. tuned.plugins.plugin_modules: kernel module 'cpufreq_conservative' not found, skipping it tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded' ---- Such error messages are harmless, so you can safely ignore them. However, to eliminate the errors, you can override the `balanced` profile, so that Tuned does not attempt to load the kernel module. For example, create the `/etc/tuned/balanced/tuned.conf` file with the following contents: ---- [main] include=balanced [modules] enabled=0 ----	Story Points:	---
Clone Of:
Clones:	1779157 (view as bug list)		Environment:
Last Closed:	2019-12-06 16:06:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1779157

Description Robin Hack 2019-06-11 08:02:44 UTC

Description of problem:


Version-Release number of selected component (if applicable):
tuned-2.11.0-5.el7.noarch


How reproducible:
always on some machines

Steps to Reproduce:
1. load balanced profile
2. check logs for ERROR
3.

Actual results:
:: [ 22:10:57 ] :: [   LOG    ] :: === [1mActual profile: balanced[m ===
:: [ 22:10:57 ] :: [  BEGIN   ] :: Running 'tuned-adm profile balanced'
:: [ 22:10:59 ] :: [   PASS   ] :: Command 'tuned-adm profile balanced' (Expected 0, got 0)
:: [ 22:11:02 ] :: [  BEGIN   ] :: Running 'tuned-adm active | grep balanced'
Current active profile: balanced
:: [ 22:11:02 ] :: [   PASS   ] :: Command 'tuned-adm active | grep balanced' (Expected 0, got 0)



:: [ 22:14:48 ] :: [   FAIL   ] :: Current system setting corresponds with selected profile. (Expected 0, got 1)
:: [ 22:14:48 ] :: [  BEGIN   ] :: Running 'cat /var/log/tuned/tuned.log | grep ERROR'
2019-06-08 22:14:48,391 ERROR    tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded'
:: [ 22:14:48 ] :: [   LOG    ] :: Output of 'cat /var/log/tuned/tuned.log | grep ERROR':
:: [ 22:14:48 ] :: [   LOG    ] :: --------------- OUTPUT START ---------------
:: [ 22:14:48 ] :: [   LOG    ] :: 2019-06-08 22:14:48,391 ERROR    tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded'
:: [ 22:14:48 ] :: [   LOG    ] :: ---------------  OUTPUT END  ---------------
:: [ 22:14:48 ] :: [   PASS   ] :: Command 'cat /var/log/tuned/tuned.log | grep ERROR' (Expected 0, got 0)


Expected results:


Additional info:

Comment 2 Ondřej Lysoněk 2019-06-11 08:52:04 UTC

Thanks for the report. It's caused by this commit:
https://github.com/redhat-performance/tuned/commit/af269d11ae3ef167

The commit adds a line to the balanced profile which tells Tuned to load the cpufreq_conservative kernel module. I believe this is needed on SUSE, because they have it compiled as a module. However in RHEL, we have it built-in in the kernel.

I'm not really sure what we should do about this. Normally we would adjust the logging levels so that the message doesn't look as bad in the log, however I don't think that's a good solution here. The log level needs to be at least WARN, so that it gets noticed on systems, where it's relevant (namely SUSE). However if we simply log it as WARN instead of ERROR, it's still going to annoy our users in RHEL, where the message is irelevant. I think the patch should not have been upstreamed in the first place.

So I see two possibilities:
a) revert the change upstream
b) revert the change downstream in RHEL and Fedora

There's also a third possibility - ideally, we would detect whether the module needs to be loaded or not. However I don't think this is worth the effort here.

Comment 6 Ondřej Lysoněk 2019-06-11 10:17:36 UTC

For the record, the errors are harmless.

Comment 8 Ondřej Lysoněk 2019-06-14 09:55:43 UTC

For the record, Jarda came up with another solution: load the kernel module 'cpufreq_conservative' in the CPU plugin, when necessary -  the kernel module is only required by the CPU plugin to set the 'conservative' CPU governor, so the CPU plugin is the logical place to load it.

Comment 14 Tomáš Hozza 2019-12-06 16:06:30 UTC

Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug.

For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/

Comment 15 RHEL Program Management 2019-12-06 16:06:37 UTC

Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto