* [PATCH] tools, cpupower, fix return checks for sysfs_get_idlestate_count()
@ 2014-12-01 14:39 Prarit Bhargava
2014-12-03 18:25 ` Thomas Renninger
0 siblings, 1 reply; 2+ messages in thread
From: Prarit Bhargava @ 2014-12-01 14:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Prarit Bhargava, Thomas Renninger, linux-pm
Red Hat and Fedora use a bug reporting tool that gathers data about
"broken" systems called sosreport. Among other things, it includes the
output of 'cpupower idle-info'. Executing 'cpupower idle-info' on a
system that has cpuidle disabled via 'cpuidle.off=1' results in a 300
second hang in the cpupower application.
ie)
[root@intel-brickland-05]# cpupower idle-info
Could not determine cpuidle driver
Analyzing CPU 0:
Number of idle states: -19
[hang]
The problem is that the cpupower code only checks for a zero return from
sysfs_get_idlestate_count(). The function can return -ENODEV (-19) as
above. This patch fixes callers to sysfs_get_idlestate_count() to check
the right return values.
Cc: Thomas Renninger <trenn@suse.de>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
---
tools/power/cpupower/utils/cpuidle-info.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/power/cpupower/utils/cpuidle-info.c b/tools/power/cpupower/utils/cpuidle-info.c
index 75e66de..458d69b 100644
--- a/tools/power/cpupower/utils/cpuidle-info.c
+++ b/tools/power/cpupower/utils/cpuidle-info.c
@@ -22,13 +22,13 @@
static void cpuidle_cpu_output(unsigned int cpu, int verbose)
{
- unsigned int idlestates, idlestate;
+ int idlestates, idlestate;
char *tmp;
printf(_ ("Analyzing CPU %d:\n"), cpu);
idlestates = sysfs_get_idlestate_count(cpu);
- if (idlestates == 0) {
+ if (idlestates < 1) {
printf(_("CPU %u: No idle states\n"), cpu);
return;
}
@@ -100,10 +100,10 @@ static void cpuidle_general_output(void)
static void proc_cpuidle_cpu_output(unsigned int cpu)
{
long max_allowed_cstate = 2000000000;
- unsigned int cstate, cstates;
+ int cstate, cstates;
cstates = sysfs_get_idlestate_count(cpu);
- if (cstates == 0) {
+ if (cstates < 1) {
printf(_("CPU %u: No C-states info\n"), cpu);
return;
}
--
1.7.9.3
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] tools, cpupower, fix return checks for sysfs_get_idlestate_count()
2014-12-01 14:39 [PATCH] tools, cpupower, fix return checks for sysfs_get_idlestate_count() Prarit Bhargava
@ 2014-12-03 18:25 ` Thomas Renninger
0 siblings, 0 replies; 2+ messages in thread
From: Thomas Renninger @ 2014-12-03 18:25 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-kernel, linux-pm
On Monday, December 01, 2014 09:39:22 AM Prarit Bhargava wrote:
> Red Hat and Fedora use a bug reporting tool that gathers data about
> "broken" systems called sosreport. Among other things, it includes the
> output of 'cpupower idle-info'. Executing 'cpupower idle-info' on a
> system that has cpuidle disabled via 'cpuidle.off=1' results in a 300
> second hang in the cpupower application.
>
> ie)
> [root@intel-brickland-05]# cpupower idle-info
> Could not determine cpuidle driver
>
> Analyzing CPU 0:
> Number of idle states: -19
> [hang]
>
> The problem is that the cpupower code only checks for a zero return from
> sysfs_get_idlestate_count(). The function can return -ENODEV (-19) as
> above. This patch fixes callers to sysfs_get_idlestate_count() to check
> the right return values.
>
> Cc: Thomas Renninger <trenn@suse.de>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-12-03 18:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-01 14:39 [PATCH] tools, cpupower, fix return checks for sysfs_get_idlestate_count() Prarit Bhargava
2014-12-03 18:25 ` Thomas Renninger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).