my cpu graph doesn’t work
You might want to open up your own thread here if you’d like that resolved.
1 Like
You shouldn’t need cpufrequtils for the cpufreq graph.
What processor is in your system?
I must admit i don’t bother looking at the cpu freq graph as it doesn’t really tell me anything useful that helps me with the operation of my ipfire. However on my mini appliance it is just working and i don’t have cpufrequtils installed.
Maybe need to look in the logs for rrd and/or collectd and the lm-sensors program.
Maybe for your cpu it is not getting any freq info.
3 Likes
AMD FX6300 6 core @3.2Ghz
so not an unusual processor type.
Maybe try running the /usr/sbin/sensors-detect program to see if it has any issues accessing any of the sensor data for the system.
Answer YES to all of the Do you want to scan for ... ? questions.
Has the graph worked in the pats and now no longer works or has it never worked?
2 Likes
it never worked. I’ll try the /usr/sbin/sensors-detect in a SSH terminal and report back.
Here is the output:
# sensors-detect version 3.6.0
# Board: ASRock 960GM/U3S3 FX
# Kernel: 6.6.47-ipfire x86_64
# Processor: AMD FX(tm)-6300 Six-Core Processor (21/2/0)
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): YES
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... Success!
(driver `k10temp')
AMD Family 16h thermal sensors... No
AMD Family 17h thermal sensors... No
AMD Family 15h power sensors... Success!
(driver `fam15h_power')
AMD Family 16h power sensors... No
Hygon Family 18h thermal sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Intel 5500/5520/X58 thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): YES
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
Found `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' Success!
(address 0x290, driver `nct6775')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): YES
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): yes
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): YES
Using driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc SB600/SB700/SB800 SMBus
Module i2c-dev loaded successfully.
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `nct6775':
* ISA bus, address 0x290
Chip `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' (confidence: 9)
Driver `fam15h_power' (autoloaded):
* Chip `AMD Family 15h power sensors' (confidence: 9)
Driver `k10temp' (autoloaded):
* Chip `AMD Family 15h thermal sensors' (confidence: 9)
Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): YES
Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors
for initialization at boot time.
You should now start the lm_sensors service to load the required
kernel modules.
Unloading i2c-dev... OK
Even after rebooting, I still get this:
Now since I ran that sensors-detect, the all computers on the network are either timing out when surfing the internet or slow at loading if the DNS resolves.
So it looks like I’m going to reinstall the OS and go back to version 187 and not execute the sensors-detect since it broke it.
When you install the system and reboot it then sensors-detect is run in the first boot run by the collectd initscript to collect all the required data of available sensors and in fact if sensors-detect is not run at all then collectd will have no information on any of the hardware sensors and would be unable to collect any data.
In the past when I have run sensors-detect I have not experienced what you have described.
I will try and see if I can get some time later this week to test that out on a vm system.
1 Like
I ran sensors detect on ipfire 188 a couple of days after I upgraded from version 187 and it caused the installation to fall apart.