You just pushed a heavy workload and the fans are screaming
You finished compiling a large project or rendered a video timeline. The desktop fans spin up to maximum speed. You want to know if the GPU is actually working at full capacity or if a background process is stuck in a loop. You open a terminal and type a familiar monitoring command, but your system uses an AMD card. The command fails. You need a reliable way to read utilization, clock speeds, and thermal output without installing proprietary software.
What the kernel actually tracks
The Linux kernel does not guess your hardware state. It reads direct registers exposed by the GPU firmware. AMD cards use the amdgpu kernel module to expose power management, thermal zones, and utilization counters. These counters live in the sysfs virtual filesystem under /sys/class/drm/ and /sys/class/hwmon/. User-space tools like radeontop and lm_sensors simply read those sysfs entries and format them for you.
Think of the kernel as a building manager with direct access to the electrical panels. The monitoring tools are just the digital readouts on the wall. You do not need to rewrite the wiring to see the numbers. The kernel already collects the data. You only need the correct interface to read it.
Fedora ships with the amdgpu module enabled by default. The module creates hardware monitoring interfaces automatically when it detects supported silicon. You do not need to compile out-of-tree drivers or modify kernel parameters. The infrastructure is already there. You just need to install the reader utilities and configure them to talk to the right interfaces.
Install and configure the monitoring stack
Start by installing the two core packages. radeontop handles real-time utilization and power metrics. lm_sensors provides the hardware monitoring framework that reads thermal zones and voltage rails.
Here is how to pull both packages from the default repositories.
sudo dnf install radeontop lm_sensors
# --refresh forces dnf to check the mirrors for updated metadata
# This prevents stale package lists from blocking the install
# radeontop provides the interactive GPU usage viewer
# lm_sensors provides the underlying hardware sensor framework
Fedora's package manager handles dependencies automatically. You do not need to enable third-party repositories for these tools. They ship in the main Fedora repositories. Run dnf upgrade --refresh once a week to keep the monitoring stack aligned with kernel updates.
After installation, you must initialize the sensor framework. The lm_sensors package does not guess which chips are on your motherboard. It requires a one-time hardware probe to generate a configuration file. This step maps I2C and SMBus addresses to readable sensor names.
Here is how to run the detection script and apply the configuration.
sudo sensors-detect
# The script probes every bus for known hardware monitoring chips
# Press Enter to accept the safe defaults for each prompt
# Say yes when asked to update /etc/sysconfig/lm_sensors
# This creates a persistent config file for the sensors service
sudo sensors
# Runs the newly configured reader to verify output
# The first run may take a second while it reads sysfs entries
The detection script writes to /etc/sysconfig/lm_sensors and /etc/sensors.d/. Never edit files in /usr/lib/sensors.d/. Those ship with the package and get overwritten on upgrade. Always modify /etc/ paths. The system merges them at runtime, so your customizations survive package updates.
Once the sensor framework is active, you can launch the GPU monitor. radeontop requires root privileges because it reads PCI configuration space and kernel debug interfaces. Standard user permissions block direct hardware register access.
Here is how to launch the interactive viewer and grab a quick metric for scripting.
sudo radeontop
# Opens the ncurses terminal interface
# Shows real-time usage, clock speeds, and power draw
# Press q to exit without interrupting background processes
sudo radeontop -d | head -n 1
# The -d flag switches to daemon mode with CSV output
# Piping to head grabs the first line for quick verification
# Useful for cron jobs or simple shell scripts
The interactive interface updates every second. It reads directly from /sys/class/drm/card0/device/ and the AMD kernel debugfs interface. The daemon mode outputs comma-separated values that you can pipe to awk, gnuplot, or a logging script.
Verify the readings match reality
Monitoring tools can drift if the kernel module fails to initialize properly. Always cross-reference the output with the raw sysfs entries. This confirms the data path is intact.
Here is how to verify the thermal zone directly from the filesystem.
cat /sys/class/hwmon/hwmon*/temp1_input
# Reads the raw millidegree value from the first thermal zone
# The kernel exposes this as a plain integer file
# Divide by 1000 in your head to get Celsius
ls -l /sys/class/hwmon/hwmon*/name
# Confirms which driver owns the sensor interface
# Look for k10temp or amdgpu in the symlink target
If sensors shows a temperature but radeontop shows zero percent usage, your GPU is likely idle. The kernel reports utilization based on compute queue activity. Desktop compositors and video playback often use the hardware video decoder, which does not register as heavy compute load. Run a Vulkan or OpenGL benchmark to push the utilization needle.
Check the service state before troubleshooting further. The lm_sensors framework runs as a user-space daemon that caches readings. If it crashes, your terminal commands will hang or return stale data.
Here is how to check the daemon health and restart it safely.
systemctl status lm_sensors.service
# Shows active state, recent log lines, and memory usage
# Always check status before restarting a monitoring service
sudo systemctl restart lm_sensors.service
# Reloads the sensor configuration without rebooting
# The daemon re-reads /etc/sensors.d/ on restart
Run journalctl -xeu lm_sensors.service if the restart fails. The x flag adds explanatory context to each log line. The e flag jumps to the end. Most sysadmins type this combination muscle-memory style when a service misbehaves.
Reboot before you debug. Half the time the symptom is gone after a clean module reload.
Common pitfalls and broken sensor output
The most frequent issue is missing temperature readings. sensors will list CPU and motherboard chips but skip the GPU entirely. This usually means the amdgpu module failed to bind or the firmware is outdated.
Here is how to verify the kernel module is loaded and functioning.
lsmod | grep amdgpu
# Lists the module and its dependency count
# A missing line means the driver did not load at boot
modinfo amdgpu
# Shows the module version and supported hardware IDs
# Compare the version against your kernel release
If the module is missing, check the boot logs. Secure Boot can block unsigned third-party modules, but amdgpu ships signed with the Fedora kernel. The real culprit is usually a firmware mismatch or a kernel regression.
Here is how to check for driver initialization failures in the journal.
journalctl -k -t amdgpu | tail -n 20
# Filters kernel messages specifically tagged with amdgpu
# The -k flag limits output to kernel ring buffer entries
# Look for "Failed to load firmware" or "PCIe link down"
If you see [drm] amdgpu: Failed to load firmware during boot, your linux-firmware package is stale. Run sudo dnf upgrade linux-firmware and reboot. The firmware package contains the microcode blobs the kernel needs to initialize the GPU's power management and thermal controllers.
Another common trap is running radeontop without sudo. The tool will silently fail or show 0.0% across all metrics. It cannot read the debugfs interface without elevated privileges. Always prefix with sudo or run from a root shell.
SELinux rarely blocks these tools, but if you see Permission denied on sysfs paths, check the audit log. Run journalctl -t setroubleshoot to read the one-line denial summaries. Do not disable SELinux to fix a monitoring script. Fix the file context or run the command with the correct privileges.
Trust the package manager. Manual file edits drift, snapshots stay.
Choose your monitoring approach
Use radeontop when you need real-time utilization, clock speeds, and power draw in a terminal interface. Use sensors when you want a consolidated view of CPU, motherboard, and GPU thermal zones. Use raw sysfs reads when you are writing a custom monitoring script and need to avoid external dependencies. Use journalctl -k -t amdgpu when the driver fails to initialize or reports hardware errors. Stay on the default Fedora stack if you only need occasional checks and do not want to maintain custom daemons.