I just installed IPFire in a barebone with this CPU:
Model name: 12th Gen Intel(R) Core™ i5-1235U
CPU Graph gives following error:
Error in RRD::graph for cpu freq: cpu9A0 is not a vname nor a number (system.cg i, cpufreq, day)
Is there some known/unknown incompatibility of this CPU with IPFire? is there a way I can see that the cores and the frequency steps are being used correctly? (am I doing something wrong?)
Thanks!
Hi David - Welcome the the IPFire Community!
Is this a new installation? Or did you migrate from a different IPFire device and do a restore?
Thanks!
It’s a totally new installation, I did install the stable first, and then the “testing”… in both I have the same issue.
I tried this from the wiki
wiki.ipfire.org - Migrate to new hardware
And other than purging all the graph information that was cumulated, nothing else has happened (so the same error in the CPU Frequency Graph
I also installed cpufreq-info and apparently it’s returning information (no error)
Should I just get used to the fact that RRD graphs do not work?
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:0.67%, 2.50 GHz:0.00%, 2.30 GHz:0.01%, 2.20 GHz:0.01%, 2.00 GHz:0.01%, 1.90 GHz:0.03%, 1.70 GHz:0.02%, 1.60 GHz:0.02%, 1.30 GHz:0.05%, 1.20 GHz:0.39%, 1.10 GHz:0.11%, 1000 MHz:0.25%, 800 MHz:0.87%, 700 MHz:0.35%, 5 00 MHz:17.93%, 400 MHz:79.29% (1172)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 2.50 GHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:2.68%, 2.50 GHz:0.00%, 2.30 GHz:0.10%, 2.20 GHz:0.00%, 2.00 GHz:0.01%, 1.90 GHz:0.03%, 1.70 GHz:0.01%, 1.60 GHz:0.01%, 1.30 GHz:0.24%, 1.20 GHz:0.01%, 1.10 GHz:0.57%, 1000 MHz:0.14%, 800 MHz:0.47%, 700 MHz:0.56%, 5 00 MHz:6.25%, 400 MHz:88.91% (633)
analyzing CPU 2:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:6.91%, 2.50 GHz:0.00%, 2.30 GHz:0.01%, 2.20 GHz:0.04%, 2.00 GHz:0.02%, 1.90 GHz:0.02%, 1.70 GHz:0.06%, 1.60 GHz:0.04%, 1.30 GHz:0.11%, 1.20 GHz:0.16%, 1.10 GHz:0.27%, 1000 MHz:0.55%, 800 MHz:0.74%, 700 MHz:1.60%, 5 00 MHz:8.83%, 400 MHz:80.63% (1473)
analyzing CPU 3:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 500 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:1.32%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.04%, 2.00 GHz:0.01%, 1.90 GHz:0.01%, 1.70 GHz:0.06%, 1.60 GHz:0.02%, 1.30 GHz:0.04%, 1.20 GHz:0.02%, 1.10 GHz:0.33%, 1000 MHz:0.20%, 800 MHz:0.26%, 700 MHz:1.53%, 5 00 MHz:8.74%, 400 MHz:87.41% (1182)
analyzing CPU 4:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 4
CPUs which need to have their frequency coordinated by software: 4
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:4.05%, 2.50 GHz:0.00%, 2.30 GHz:0.19%, 2.20 GHz:0.02%, 2.00 GHz:0.01%, 1.90 GHz:0.06%, 1.70 GHz:0.04%, 1.60 GHz:0.09%, 1.30 GHz:0.08%, 1.20 GHz:0.22%, 1.10 GHz:0.03%, 1000 MHz:0.20%, 800 MHz:0.37%, 700 MHz:0.66%, 5 00 MHz:5.35%, 400 MHz:88.65% (868)
analyzing CPU 5:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 5
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:4.32%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.54%, 1.90 GHz:0.01%, 1.70 GHz:0.14%, 1.60 GHz:0.24%, 1.30 GHz:0.01%, 1.20 GHz:0.00%, 1.10 GHz:0.19%, 1000 MHz:0.46%, 800 MHz:2.19%, 700 MHz:2.27%, 5 00 MHz:5.80%, 400 MHz:83.84% (538)
analyzing CPU 6:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 6
CPUs which need to have their frequency coordinated by software: 6
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:2.34%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.90 GHz:0.00%, 1.70 GHz:0.06%, 1.60 GHz:0.00%, 1.30 GHz:0.00%, 1.20 GHz:0.09%, 1.10 GHz:0.09%, 1000 MHz:0.35%, 800 MHz:0.61%, 700 MHz:0.85%, 5 00 MHz:2.21%, 400 MHz:93.40% (391)
analyzing CPU 7:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:2.81%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.01%, 2.00 GHz:0.00%, 1.90 GHz:0.00%, 1.70 GHz:0.00%, 1.60 GHz:0.00%, 1.30 GHz:0.00%, 1.20 GHz:0.12%, 1.10 GHz:0.00%, 1000 MHz:0.41%, 800 MHz:1.90%, 700 MHz:1.04%, 5 00 MHz:1.98%, 400 MHz:91.72% (142)
analyzing CPU 8:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 8
CPUs which need to have their frequency coordinated by software: 8
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:2.82%, 2.50 GHz:0.00%, 2.30 GHz:0.01%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.90 GHz:0.00%, 1.70 GHz:0.00%, 1.60 GHz:0.00%, 1.30 GHz:0.21%, 1.20 GHz:0.25%, 1.10 GHz:0.00%, 1000 MHz:0.00%, 800 MHz:1.11%, 700 MHz:0.79%, 5 00 MHz:5.43%, 400 MHz:89.37% (307)
analyzing CPU 9:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 9
CPUs which need to have their frequency coordinated by software: 9
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 2.50 GHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:7.09%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.90 GHz:0.00%, 1.70 GHz:0.00%, 1.60 GHz:0.01%, 1.30 GHz:0.14%, 1.20 GHz:0.00%, 1.10 GHz:0.34%, 1000 MHz:0.00%, 800 MHz:1.40%, 700 MHz:1.20%, 5 00 MHz:9.36%, 400 MHz:80.45% (229)
analyzing CPU 10:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 10
CPUs which need to have their frequency coordinated by software: 10
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:1.33%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.11%, 1.90 GHz:0.00%, 1.70 GHz:0.00%, 1.60 GHz:0.00%, 1.30 GHz:0.00%, 1.20 GHz:0.00%, 1.10 GHz:0.00%, 1000 MHz:0.03%, 800 MHz:0.43%, 700 MHz:0.11%, 5 00 MHz:3.83%, 400 MHz:94.16% (108)
analyzing CPU 11:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 11
CPUs which need to have their frequency coordinated by software: 11
maximum transition latency: 10.0 us.
hardware limits: 400 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1 .90 GHz, 1.70 GHz, 1.60 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 70 0 MHz, 500 MHz, 400 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil
current policy: frequency should be within 400 MHz and 2.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 400 MHz (asserted by call to hardware).
cpufreq stats: 2.50 GHz:1.95%, 2.50 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.90 GHz:0.02%, 1.70 GHz:0.00%, 1.60 GHz:0.19%, 1.30 GHz:0.68%, 1.20 GHz:0.33%, 1.10 GHz:0.05%, 1000 MHz:0.02%, 800 MHz:0.04%, 700 MHz:0.17%, 5 00 MHz:5.50%, 400 MHz:91.05% (194)
And then I found this:
12890 – ACPI Thermal-Zone Temp Graph - temp9A0 is not a vname nor a number (ipfire.org)
CpuFreq graph error - IPFire Community
Sounds suspiciously similar and from what I can see the bug is not yet fixed… where do I find this graphs.pl file so that I can try to apply the patch myself?
@deibit ,
the file is at /var/ipfire.
The findings in the article cited and in bugzilla are right.
The line
,"LINE1:cpu".$i.$color{"color1$j"}."A0:cpu ".$i." "
producing the error tries to build the string
LINE1:cpu<x><cy>A0:cpu<x>
with <x> being the cpu# and <cy> color<x+1+10>
Generating x+1+10 with '1<x+1>' only functions for out of 0…8 
, for x=9 you the string ‘110’, not ‘21’ ( = 9+1+10 )
The color names in colors.txt are ‘color1’ … ‘color25’, so the suggestion to use $color{$i}sholud be okay for all systems with 24 cpus maximal.
Yay!
I did change the string to
,"LINE1:cpu".$i.$color{"color$j"}."A0:cpu ".$i." "
as suggested, and now I can see all 12 CPUs!! (I am happy man)
I hope that @luani manages to fix this in the official version… this got me confused for some hours 
Maybe you could add a comment to that bug report, referencing this thread? I think it would be useful for the project.
Hi, thanks for the reminder!
Could you please try this patch because I don’t have a system with that many CPU cores:
diff --git a/config/cfgroot/graphs.pl b/config/cfgroot/graphs.pl
index 3368e5aad..1d93df361 100644
--- a/config/cfgroot/graphs.pl
+++ b/config/cfgroot/graphs.pl
@@ -1098,10 +1098,10 @@ sub updatecpufreqgraph {
);
for(my $i = 0; $i < $cpucount; $i++) {
- my $j=$i+1;
+ my $j = ($i % 10) + 11;
push(@command,"DEF:cpu".$i."_=".$mainsettings{'RRDLOG'}."/collectd/localhost/cpufreq/cpufreq-".$i.".rrd:value:AVERAGE"
,"CDEF:cpu".$i."=cpu".$i."_,1000000,/"
- ,"LINE1:cpu".$i.$color{"color1$j"}."A0:cpu ".$i." "
+ ,"LINE1:cpu".$i.$color{"color$j"}."A0:cpu ".$i." "
,"GPRINT:cpu".$i.":MAX:%3.0lf Mhz"
,"GPRINT:cpu".$i.":AVERAGE:%3.0lf Mhz"
,"GPRINT:cpu".$i.":MIN:%3.0lf Mhz"
--
This limits the color index to 11-20, starting at 12, ensuring that the colors on existing systems won’t be changed.
Only for completeness. This code produces the same colours for CPU0/CPU10, CPU1/CPU11, …
This aspect should be tested also. Are these graphs distinguishable enough? How is the size of the picture? Would it help to split into several graphs, one for 0 … 9, for 10…19, …?
This is the graph with @luani patch:
Yes, the colors cycle after cpu10
Graph is nice “to see”, but yes, @bbitsch has a point, it’s too “compressed” to be able to get something meaningful from it. Not sure is splitting is going to be the most optimum workaround… but I guess we don’t have more choices? (overlapping 12 colors in such a small space is always going to look like a colorful fuzzy nebula)
Yes unfortunately there aren’t many more usable colors available. Color21 is all white #FFFFFF.
I could make the index start at 12 and wrap around to 1. But looking at the screenshot I think the best option would be to increase the diagram height.
Keep in mind anything changed is temporary. An update will wipe out these changes.
The command to set the height is (with current value):
--height=300
So you may want to try 600.
I would try inserting it here (see height above COMMENTs):
sub updatecpufreqgraph {
my $cpucount = `ls -dA $mainsettings{'RRDLOG'}/collectd/localhost/cpu-*/ 2>/dev/null | wc -l`;
my $period = $_[0];
my @command = (
@GRAPH_ARGS,
"-",
"--start",
"-1".$period,
"-r",
"-t ".$Lang::tr{'cpu frequency per'}." ".$Lang::tr{$period."-graph"},
"-v MHz",
"--color=SHADEA".$color{"color19"},
"--color=SHADEB".$color{"color19"},
"--color=BACK".$color{"color21"},
"--height=600", # < - test here
"COMMENT:".sprintf("%-10s",$Lang::tr{'caption'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'maximal'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'average'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'minimal'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'current'})."\\j"
);
This has not been tested.
EDIT: Need to add an =. This should be:
--height=600
I think it would make sense to maximize the colors up to the maximum possible… (being selfish, 12 sounds like a good number) 
for example hwtemp Graph in my installation shows 15 different colors for the 15 different sensors (even though the hwtemp graph is totally unreadable, is even smaller than the cpu one)
hwtemp graph uses a random color, generated by function random_hex_color.
Nice find!
It looks like a few graphs use this!
by the way @luani
If you look at the image I sent:
From cpu10, the Mhz information is not aligned with the previous ones
changing the height to 200 ( was 300 ) and commenting out --full-size-mode, may lead to nicer pictures
Hi, here’s another attempt:
diff --git a/config/cfgroot/graphs.pl b/config/cfgroot/graphs.pl
index 3368e5aad..d6f529197 100644
--- a/config/cfgroot/graphs.pl
+++ b/config/cfgroot/graphs.pl
@@ -31,7 +31,9 @@ require "${General::swroot}/lang.pl";
require "${General::swroot}/header.pl";
# Graph image size in pixel
-our %image_size = ('width' => 910, 'height' => 300);
+# width/height: approximate size of final graph image, mainly used for placeholders
+# canvas width/height: size of the actual data area, without labeling
+our %image_size = ('width' => 900, 'height' => 300, 'canvas_width' => 800, 'canvas_height' => 200);
# List of all available time ranges
our @time_ranges = ("hour", "day", "week", "month", "year");
@@ -48,15 +50,12 @@ my @GRAPH_ARGS = (
# For a more 'organic' look
"--slope-mode",
- # HxW define the size of the output image
- "--full-size-mode",
-
# Watermark
"-W www.ipfire.org",
# Default size
- "-w $image_size{'width'}",
- "-h $image_size{'height'}",
+ "-w $image_size{'canvas_width'}",
+ "-h $image_size{'canvas_height'}",
# Use alternative grid
"--alt-y-grid",
@@ -1090,18 +1089,19 @@ sub updatecpufreqgraph {
"--color=SHADEA".$color{"color19"},
"--color=SHADEB".$color{"color19"},
"--color=BACK".$color{"color21"},
- "COMMENT:".sprintf("%-10s",$Lang::tr{'caption'}),
+ "COMMENT:".sprintf("%-15s",$Lang::tr{'caption'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'maximal'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'average'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'minimal'}),
"COMMENT:".sprintf("%15s",$Lang::tr{'current'})."\\j"
);
+ my $j = 11;
for(my $i = 0; $i < $cpucount; $i++) {
- my $j=$i+1;
+ $j++; $j = 1 if $j > 20;
push(@command,"DEF:cpu".$i."_=".$mainsettings{'RRDLOG'}."/collectd/localhost/cpufreq/cpufreq-".$i.".rrd:value:AVERAGE"
,"CDEF:cpu".$i."=cpu".$i."_,1000000,/"
- ,"LINE1:cpu".$i.$color{"color1$j"}."A0:cpu ".$i." "
+ ,"LINE1:cpu".$i.$color{"color$j"}."A0:cpu ".$i." "
,"GPRINT:cpu".$i.":MAX:%3.0lf Mhz"
,"GPRINT:cpu".$i.":AVERAGE:%3.0lf Mhz"
,"GPRINT:cpu".$i.":MIN:%3.0lf Mhz"
--