You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Landing Page, System. on FreeBSD, the CPU frequency shows NaN GHz #1131
CPU frequency displays as "NaN GHz" on the netdata landing page (System tab) on FreeBSD, despite the FreeBSD plugin successfully collecting CPU frequency data for charting.
Environment
OS: FreeBSD 15.0-RELEASE (amd64)
Netdata Version: v2.6.3
CPU: Intel Pentium N3700 @ 1.60GHz
Installation: FreeBSD pkg/ports (custom)
Plugin: freebsd.plugin
Expected Behavior
The landing page System tab should display the current CPU frequency in GHz, e.g., "0.88 GHz" or "1.60 GHz".
Actual Behavior
The landing page displays "NaN GHz" for CPU frequency.
The landing page attempts to render the string "unknown" as a numeric value, resulting in "NaN GHz".
Root Cause Analysis
The FreeBSD plugin has two separate code paths:
Time-series data collection (working): Reads dev.cpu.0.freq sysctl and creates charts ✅
Metadata population (broken): Should populate cpu_freq field in host info but returns "unknown" ❌
The metadata field is never populated with the actual CPU frequency value, despite being successfully collected for charting purposes.
Steps to Reproduce
Install netdata v2.6.3 on FreeBSD 15.0-RELEASE
Ensure dev.cpu.0.freq sysctl exists and returns valid data
Navigate to netdata landing page (port 19999 or via reverse proxy)
Click "System" tab at bottom of landing page
Observe "CPU Frequency" field displays "NaN GHz"
Verify chart works: access /api/v1/data?chart=cpu.scaling_cur_freq shows valid data
Expected Fix
The freebsd.plugin should populate the cpu_freq metadata field in /api/v1/info with the current CPU frequency value (e.g., "880" or "0.88" depending on expected format) when it successfully collects this data for charting.
Workaround
None. The issue is cosmetic - all charts function correctly. Users can ignore the "NaN GHz" display on the landing page.
Additional Notes
This may affect other FreeBSD systems where dev.cpu.N.freq sysctl exists
The related dev.cpu.temperature sysctl genuinely doesn't exist on this hardware (expected)
System has 4 CPU cores, all reporting valid frequency data via sysctl
Activity
rickhull commentedon Jan 1, 2026
Evidence
1. CPU Frequency Data is Available via sysctl
2. Netdata Collector is Running
The freebsd.plugin is actively collecting CPU frequency data:
{ "plugin": "freebsd.plugin", "module": "dev.cpu.0.freq" }3. Time-Series Chart Works Correctly
The chart
cpu.scaling_cur_freqexists and contains valid data:This chart displays correctly and shows valid frequency values when accessed via
/api/v1/data?chart=cpu.scaling_cur_freq.4. Metadata API Returns "unknown"
The
/api/v1/infoendpoint (used by the landing page) shows:{ "cpu_freq": "unknown", "host_labels": { "_system_cpu_freq": "unknown" } }The landing page attempts to render the string "unknown" as a numeric value, resulting in "NaN GHz".
Root Cause Analysis
The FreeBSD plugin has two separate code paths:
dev.cpu.0.freqsysctl and creates charts ✅cpu_freqfield in host info but returns "unknown" ❌The metadata field is never populated with the actual CPU frequency value, despite being successfully collected for charting purposes.
Steps to Reproduce
dev.cpu.0.freqsysctl exists and returns valid data/api/v1/data?chart=cpu.scaling_cur_freqshows valid dataExpected Fix
The freebsd.plugin should populate the
cpu_freqmetadata field in/api/v1/infowith the current CPU frequency value (e.g., "880" or "0.88" depending on expected format) when it successfully collects this data for charting.Workaround
None. The issue is cosmetic - all charts function correctly. Users can ignore the "NaN GHz" display on the landing page.
Additional Notes
dev.cpu.N.freqsysctl existsdev.cpu.temperaturesysctl genuinely doesn't exist on this hardware (expected)fix(freebsd): CPU frequency detection returns "unknown" causing NaN d…
ktsaou commentedon Jan 28, 2026
Sorry for the delay.
Fixed in netdata/netdata#21658