Performance Troubleshooting¶

This guide covers common performance issues and their solutions for the BC-250.

Quick Diagnostics¶

Before troubleshooting specific issues, run these commands to check your system status:

# Check GPU frequency and temperature
sensors

# Check GPU clock state (live)
# Pick the right card: ls -l /sys/class/drm/ | grep card  (usually card0 for the BC-250)
watch -n 1 cat /sys/class/drm/card0/device/pp_dpm_sclk
watch -n 1 cat /sys/class/drm/card0/device/pp_dpm_mclk

# Note: `gpu_busy_percent` does NOT work on the BC-250 (amdgpu driver leaves
# the metric field uninitialised, hence the famous MangoHud 655% bug).
# See the MangoHud admonition further down for the fix and root cause.

# Check if GPU driver is loaded
lspci -k | grep -A 3 VGA

# Verify Mesa version
glxinfo | grep "OpenGL version"

# Check governor status
systemctl status cyan-skillfish-governor-smu
# or if using TT governor:
# systemctl status cyan-skillfish-governor-tt

GPU Locked at 1500MHz¶

Symptoms: - GPU frequency stuck at 1500MHz regardless of load - Low FPS in games despite acceptable temperatures - radeontop or monitoring tools show constant 1500MHz

Cause: The default GPU governor is locked by BIOS. Without a user-space governor, the GPU cannot scale frequency dynamically.

Solution: Install GPU Governor

The BC-250 requires a custom GPU governor to enable dynamic frequency scaling between 350-2300MHz (patched kernel) or 1000-2000MHz (unpatched kernel).

Option 1: Cyan Skillfish Governor SMU (Recommended)¶

Features: - Continuous frequency adjustment via SMU firmware calls - Maintains GPU utilization 70-95% (configurable) - No kernel patch required on any distro - 24ms burst-to-max time - More responsive to burst loads

Installation:

Fedora/RPM:

dnf copr enable filippor/bazzite
dnf install cyan-skillfish-governor-smu

Arch/AUR:

yay -S cyan-skillfish-governor-smu

Debian/Ubuntu: Grab the latest cyan-skillfish-governor-smu_*_amd64.deb from filippor's releases (shipped since v0.4.10) and install it with sudo apt install ./cyan-skillfish-governor-smu_*_amd64.deb, or extract the cyan-skillfish-governor-smu-*-x86_64-linux.tar.gz from the same page and run sudo ./scripts/install.sh.

Configuration:

The governor uses voltage/frequency pairs. Edit the config file and add as many stable points as you've tested:

safe-points = [
    { freq_mhz = 350,  voltage_mv = 570 },
    { freq_mhz = 860,  voltage_mv = 600 },
    { freq_mhz = 1090, voltage_mv = 650 },
    { freq_mhz = 1280, voltage_mv = 700 },
    { freq_mhz = 1460, voltage_mv = 750 },
    { freq_mhz = 1620, voltage_mv = 800 },
    { freq_mhz = 1760, voltage_mv = 850 },
    { freq_mhz = 1890, voltage_mv = 900 },
    { freq_mhz = 2030, voltage_mv = 950 },
    { freq_mhz = 2090, voltage_mv = 975 },
    { freq_mhz = 2140, voltage_mv = 1000 },
    { freq_mhz = 2230, voltage_mv = 1050 },
]

load_target = { min = 70, max = 95 }

Test Your Values

Default values are conservative. Test stability for your specific board:

# Stop the governor
sudo systemctl stop cyan-skillfish-governor-smu

# Manually set frequency/voltage
echo vc 0 <CLOCK> <VOLTAGE> > /sys/devices/pci0000:00/0000:00:08.1/0000:01:00.0/pp_od_clk_voltage

# Run stress test (benchmark, game, etc.)
# If stable, add to config. If crashes, increase voltage or lower frequency.

Enable and start:

sudo systemctl enable --now cyan-skillfish-governor-smu

GPU Frequency Not Scaling Above 2000MHz¶

Symptoms: - Governor installed but GPU won't go above 2000MHz - Governor config shows max 2300MHz but actual frequency limited

Cause: Kernel doesn't have the frequency range patch.

Solution: Apply Kernel Patch

The BC-250 needs a kernel patch to unlock frequency range from 500-2500MHz (default is 1000-2000MHz).

Pre-patched Kernels:

Bazzite: Current Bazzite kernels do not carry the patch. Use the SMU governor instead, which does not need it (see Bazzite Setup).

CachyOS:

# CachyOS has pre-patched kernels in their repo
paru -S linux-cachyos-lts-headers

Fedora/Arch - Manual Patch:

Download the patch:

wget https://raw.githubusercontent.com/mothenjoyer69/bc250-documentation/main/kernel-patches/amdgpu-frequency-range.patch

Apply to kernel source and recompile, or use a tool like dkms or CachyOS kernel manager.

Verification:

cat /sys/class/drm/card0/device/pp_od_clk_voltage
# Should show range up to 2300MHz or higher

Software Rendering (llvmpipe) Instead of GPU¶

Symptoms: - glxinfo | grep "OpenGL renderer" shows "llvmpipe" - Games extremely slow (5-10 FPS) - Steam shows "Software Rendering" in system info

Diagnostic:

glxinfo | grep "OpenGL renderer"
# Bad:  OpenGL renderer string: llvmpipe (LLVM 15.0.0, 256 bits)
# Good: OpenGL renderer string: AMD Radeon Graphics (gfx1013, LLVM 15.0.0, DRM 3.54, 6.12.0)

vulkaninfo --summary
# Should show AMD RADV driver

Cause 1: Mesa Too Old

Solution: Upgrade to Mesa 25.1.3 or newer

Fedora 43+:

# Mesa 25.1+ is in official repos
sudo dnf update mesa*

Fedora 42 is End of Life

Upgrade to Fedora 43 which ships Mesa 25.x in repos.

Arch/Manjaro:

# Install from official repos
sudo pacman -S mesa

Verification:

glxinfo | grep "OpenGL version"
# Should show Mesa 25.1.3 or higher

Cause 2: Wrong Graphics Adapter Selected

Some games (especially Red Dead Redemption 2) default to software rendering.

Solution:

Check available adapters:

vulkaninfo --summary

In-game, change graphics adapter number to match the GPU (not llvmpipe).

For RDR2 specifically, launch with:

-useMaximumSettings

Cause 3: Driver Not Loaded

Check if amdgpu driver is loaded:

lspci -k | grep -A 3 VGA
# Should show "Kernel driver in use: amdgpu"

If not loaded, check:

dmesg | grep amdgpu
# Look for errors

Common fix - ensure these kernel parameters are set (and nomodeset is removed):

# Edit /etc/default/grub (sg_display=0 only needed for kernels < 6.10)
GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.sg_display=0"

# Regenerate grub config
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # Fedora
sudo grub-mkconfig -o /boot/grub/grub.cfg    # Arch

Low FPS / Poor Gaming Performance¶

Check GPU Utilization¶

# Monitor GPU clock state under load (proxy for utilisation since gpu_busy_percent is broken on BC-250)
watch -n 1 cat /sys/class/drm/card0/device/pp_dpm_sclk

# If the * marker sits at the lowest level under a heavy game = governor not boosting
# If it sits at the top level = GPU is loaded; check temps and thermal throttle
# Alternative: `radeontop` for a busier overview (apt/dnf/pacman install radeontop)

Issue: Governor Not Installed¶

See "GPU Locked at 1500MHz" section above.

Issue: Broken Kernel Version¶

Symptoms: - Previously working setup suddenly has poor performance after kernel update - Random GPU crashes under load - System freezes during gaming - Running kernel 6.15.0-6.15.6 or 6.17.8-6.17.10

Solution:

Install Working Kernel

AVOID BROKEN KERNEL VERSIONS

Kernel 6.15.0-6.15.6 and 6.17.8-6.17.10 break GPU driver support. Use 6.18.18 LTS (recommended) or 6.17.11+ for best performance.

Arch/Manjaro:

# Option 1: Install working kernel (6.17.11+ or 6.18.x)
sudo pacman -S linux  # Check version is 6.17.11+ or 6.18.x
# Option 2: Install LTS kernel for guaranteed stability
sudo pacman -S linux-lts linux-lts-headers
# Set as default in bootloader

CachyOS:

# Check version first
paru -S linux-cachyos  # Ensure it's 6.17.11+ or 6.18.x
# Or for LTS stability:
paru -S linux-cachyos-lts linux-cachyos-lts-headers

Fedora:

# Check current kernel
uname -r

# Install older kernel from koji if needed
# Or wait for kernel fixes

Issue: IOMMU Causing Crashes¶

Symptoms: - Random system crashes under GPU load - Weird performance issues - System hangs

IOMMU is Broken on BC-250

IOMMU MUST be disabled in BIOS. It is broken on BC-250 and causes crashes, display failures, and instability.

Solution:

Disable IOMMU in BIOS (required), or add kernel parameter as backup:

amd_iommu=off

Issue: Game-Specific Optimizations¶

Steam Launch Options:

# FSR enabled
WINE_FULLSCREEN_FSR=1 %command%

# Vulkan backend
PROTON_USE_WINED3D=0 %command%

# Gamescope for consistent frametimes
gamescope -W 1920 -H 1080 -f -- %command%

Thermal Throttling¶

Symptoms: - Performance starts good then degrades after 5-15 minutes - Temperatures above 85-90C - GPU frequency drops under sustained load

Check Temperatures:

watch -n 1 sensors

Safe operating temperatures: - 70-85C: Normal under load - 85-90C: High but acceptable - 90C+: Thermal throttling likely

Solutions:

1. Improve Cooling¶

Arctic P12 Max recommended (high static pressure: 3.27 mmH2O)

Alternative good options: - Noctua NF-A12x25 (2.34 mmH2O) - Arctic P14 PWM (2.4 mmH2O)

Fan configuration:

# Set fans to full speed in BIOS (for testing)
# Or use fan control software

2. Repaste / Replace Thermal Pads¶

APU die: Use quality thermal paste (Arctic MX-4, Noctua NT-H1) or PTM7950 phase-change pad
Memory/VRM: 2mm thermal pads (verify thickness first)
Ensure heatsink is properly secured

3. Undervolt GPU¶

If thermal throttling persists, try undervolting:

# Example: 2000MHz at 940mV instead of 1000mV
echo vc 0 2000 940 > /sys/devices/pci0000:00/0000:00:08.1/0000:01:00.0/pp_od_clk_voltage
echo c > /sys/devices/pci0000:00/0000:00:08.1/0000:01:00.0/pp_od_clk_voltage

Test stability with benchmarks. If stable, update governor config.

VRAM Allocation Issues¶

Checking Current VRAM Split¶

# Total system RAM
free -h

# GPU VRAM visible
sudo lshw -C display | grep -i memory

Issue: Game Crashes with "Out of Memory"¶

Symptoms: - Games crash after loading - Artifacts then crash (Company of Heroes 3, RDR2) - "Out of memory" errors

Common with: 512MB dynamic allocation + ZRAM enabled

Solution 1: Use Fixed VRAM Allocation

Boot into BIOS and change VRAM allocation: - For most games: 4GB VRAM / 12GB RAM - For competitive/esports: 6GB VRAM / 10GB RAM - For VRAM-heavy games: 8GB VRAM / 8GB RAM or 10GB VRAM / 6GB RAM

Dynamic Allocation Issues

512MB dynamic allocation conflicts with ZRAM on some games. Use fixed allocation instead.

Solution 2: Disable ZRAM

# Disable ZRAM
sudo systemctl stop zram-swap
sudo systemctl disable zram-swap

Solution 3: Replace ZRAM with zswap (Better for RAM-Hungry Games)

zswap compresses swap in RAM before writing to disk, avoiding ZRAM's VRAM conflicts while still helping with memory pressure.

Bazzite setup:

# Disable zram
echo "" | sudo tee /etc/systemd/zram-generator.conf

# Set up swapfile first (see https://docs.bazzite.gg/Advanced/swapfile/)

# Enable lz4 drivers in initramfs
rpm-ostree initramfs --enable \
  --arg=--add-drivers \
  --arg=lz4 \
  --arg=--add-drivers \
  --arg=lz4_compress

# Add kernel parameters
rpm-ostree kargs --append-if-missing="zswap.enabled=1 zswap.max_pool_percent=25 zswap.compressor=lz4"

# Reboot, then set swappiness
echo 180 | sudo tee /proc/sys/vm/swappiness

Verify: grep -r . /sys/module/zswap/parameters/

zswap and SSD Wear

zswap eventually writes to your swap file on disk. Not recommended on slow storage devices.

Solution 4: Increase VRAM Visibility (Advanced)

For LLM/AI workloads that need more than 12GB VRAM:

Add to kernel command line:

amdgpu.gttsize=14750 ttm.pages_limit=3959290 ttm.page_pool_size=3959290

This allows GPU to allocate up to ~14.75GB VRAM. Limit usage to 14.25-14.5GB in applications to avoid crashes.

Stuttering and Frame Pacing¶

Issue: Inconsistent Frame Times¶

Symptoms: - FPS counter shows 60+ but feels choppy - Frame time graph shows spikes - Stuttering during gameplay

Solution 1: Use Gamescope

Gamescope provides consistent frame pacing:

# Install gamescope
sudo dnf install gamescope  # Fedora
sudo pacman -S gamescope    # Arch

# Launch game through gamescope
gamescope -W 1920 -H 1080 -f -- %command%

# With frame limit
gamescope -W 1920 -H 1080 -r 60 -f -- %command%

Solution 2: Disable Compositor (X11)

For KDE Plasma (X11):

# Disable compositor in System Settings > Display > Compositor
# Or use keyboard shortcut: Alt+Shift+F12

Solution 3: Use Wayland

Wayland generally has better frame pacing than X11.

Solution 4: Audio Configuration

Some games (especially emulators) have frame pacing tied to audio:

# Check PulseAudio/PipeWire sample rate
pactl info | grep "Default Sample"

# Lock to 48kHz
# Edit /etc/pulse/daemon.conf (PulseAudio) or PipeWire config
default-sample-rate = 48000

For Ryujinx (Switch emulator): Change audio backend in settings can dramatically improve performance.

Issue: Video Playback Stutters, Feels Like Slow Internet¶

Symptoms: - YouTube and other video playback stutters or stalls while games run fine - Feels like a network problem, but downloads and speed tests are fine - Audio over DisplayPort is silent, slow or desynced at the same time

Cause: the DisplayPort audio clock bug, on kernels that still have its large error (older than 6.12.78, 6.18.20, 6.19.10 or 7.0; see which kernels are affected). PipeWire drives its whole graph off the HDMI/DisplayPort sink's clock, so a sink that consumes samples at roughly 39.5 kHz while applications feed it 48 kHz stalls the shared media clock, and everything synced to audio stutters with it. On the tested board this presented as unexplained browser-video stutter on an otherwise healthy box, and fixing the audio clock fixed the "slow internet" at the same moment.

Check your kernel and the audio clock before debugging the network or GPU: the audio page has the kernel table, the two-minute measurement and a workaround for kernels that cannot be updated yet.

Tested by: @Weijtmans. BC-250, Bazzite (Fedora Atomic 43), kernel 6.17.7-ba29.

System Configuration Issues¶

Kernel Parameters (Optimal)¶

Edit /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.sg_display=0 mitigations=off"

Explanation: - amdgpu.sg_display=0: Required for kernel < 6.10 (doesn't hurt on newer) - mitigations=off: +18 FPS in Cyberpunk 2077 (60→78 FPS) but reduces security

Security Warning

mitigations=off disables CPU vulnerability mitigations. Only use if you trust all code running on the system.

Regenerate grub:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # Fedora
sudo grub-mkconfig -o /boot/grub/grub.cfg    # Arch

Remove nomodeset¶

Critical: Remove nomodeset After Driver Installation

nomodeset is ONLY for installation. It disables GPU acceleration. Remove it after Mesa is installed.

Check if present:

cat /etc/default/grub | grep nomodeset

If found, remove it and regenerate grub config.

Performance Monitoring Tools¶

Real-time Monitoring¶

MangoHud (in-game overlay):

# Install
sudo dnf install mangohud  # Fedora
sudo pacman -S mangohud    # Arch

# Use in Steam launch options
mangohud %command%

# Or global config in ~/.config/MangoHud/MangoHud.conf

MangoHud reports 655% GPU usage on BC-250

The BC-250 amdgpu driver does not populate the GPU activity field of /sys/.../gpu_metrics. Bytes 0x1C-0x1D stay at 0xFFFF, MangoHud reads that as 65535 and divides by 100, so the overlay shows 655% GPU load. Reproduced on Fedora 43, kernel 7.0.9-105.fc43.x86_64, MangoHud 0.8.2.

Fix: run cyan-skillfish-governor-smu (smu branch) with its defaults. The governor bind-mounts a writable tmpfs file over gpu_metrics and writes a sampled activity value (busy-flag method) into byte 0x1C every cycle. Anything that reads gpu_metrics (MangoHud, radeontop, etc.) then sees a sane percent. No MangoHud config change required.

# /etc/cyan-skillfish-governor-smu/config.toml — defaults shown for reference
[gpu-usage]
fix-metrics = true
method = "busy-flag"
flush-every = 10

Verified live: with the governor stopped, bytes at offset 0x1C of gpu_metrics read ffff. With the governor running, the same bytes read 0000 at idle (0%). Bind mount is visible in /proc/self/mountinfo while the service is active.

Source: filippor/cyan-skillfish-governor smu branch — src/gpu_usage_fix.rs.

Radeontop (terminal):

sudo dnf install radeontop
radeontop

Sensors (temperatures/voltages):

watch -n 1 sensors

CoolerControl (GUI):

# Fedora/Bazzite
ujust install-coolercontrol

# Provides fan control and sensor monitoring

Benchmarking¶

Unigine Superposition:

# Good for thermal/stability testing
# 1080p Extreme preset
# Stock BC-250: ~3888 score
# 2.22GHz OC: ~4118 score

vkmark (Vulkan):

sudo dnf install vkmark
vkmark

Cyberpunk 2077 Benchmark: Popular community test - consistent results: - Stock: ~57 FPS (1080p high) - 2.22GHz: ~60 FPS - With mitigations=off: +15-20 FPS

Testing GPU Load on a Headless BC-250¶

A lot of BC-250 builds run headless (LLM server, render farm, etc). When you want to verify the GPU is actually being loaded by your workload, two pitfalls to avoid:

Don't use glmark2 --off-screen to test GPU load on a headless box

Without a display, glmark2 --off-screen silently falls back to LLVMpipe (CPU software rendering). The GPU does nothing, gpu_busy_percent stays at 0, the governor never boosts, and you may chase a phantom "governor doesn't work" bug for hours. This is documented experience from BC-250 maintainers.

Use one of these to load the GPU for real:

# Vulkan compute, deterministic
clpeak

# Real-world Vulkan workload
llama-bench -m model.gguf -ngl 99

# Vulkan rendering benchmark (offscreen works correctly)
vkmark

To confirm the GPU is genuinely loaded before drawing any conclusions from a test, check the GPU clock and power are actually climbing:

# In another terminal while your test runs
watch -n 1 cat /sys/kernel/debug/dri/0/amdgpu_pm_info 2>/dev/null \
    | grep -E "GFX|SCLK|MCLK|^[[:space:]]*[0-9]+\.[0-9]+ W"

If SCLK stays at idle and power stays under 60 W during your "load test", the test isn't loading the GPU and any conclusions you draw from it are noise.

Distribution-Specific Issues¶

Fedora¶

Issue: MTG Arena crashes GUI - Confirmed issue on Fedora with Gnome - Works fine on Manjaro - Try KDE Plasma instead of Gnome

Bazzite¶

Issue: Freeze on Sleep - Known issue: system appears frozen when entering sleep - Solution: Press power button to wake (don't hold, just press)

Issue: Bazzite Update Breaks System - If an update causes issues, rollback:

rpm-ostree status
rpm-ostree rollback

CachyOS¶

Issue: Installation ISO Won't Boot - Use LTS kernel ISO - Build custom ISO with LTS kernel (see guide in System Configuration section)

Quick Performance Checklist¶

Use this checklist to verify your system is properly configured:

Quick test:

# This should show GPU scaling dynamically
watch -n 0.5 'cat /sys/class/drm/card0/device/pp_dpm_sclk && cat /sys/class/drm/card0/device/pp_dpm_mclk'

# Run a game or benchmark
# Frequency should scale from ~1000MHz idle to 2000+MHz under load
# GPU utilization should be 80-100% in demanding scenes

Getting Help¶

If you're still experiencing performance issues after following this guide:

Gather system information:

# Create a system report
uname -r                    # Kernel version
glxinfo | grep -i mesa      # Mesa version
sensors                     # Temperatures
systemctl status cyan-skillfish-governor-smu  # Governor status
dmesg | grep amdgpu | tail -50    # Recent GPU messages

Join the Discord community:
BC-250 Discord: Largest community, most active support
Search for your specific issue first - likely already solved
Check GitHub documentation:
https://github.com/mothenjoyer69/bc250-documentation
https://github.com/AMD-BC-250/documentation

Performance Troubleshooting¶

Quick Diagnostics¶

GPU Locked at 1500MHz¶

Option 1: Cyan Skillfish Governor SMU (Recommended)¶

GPU Frequency Not Scaling Above 2000MHz¶

Software Rendering (llvmpipe) Instead of GPU¶

Low FPS / Poor Gaming Performance¶

Check GPU Utilization¶

Issue: Governor Not Installed¶

Issue: Broken Kernel Version¶

Issue: IOMMU Causing Crashes¶

Issue: Game-Specific Optimizations¶

Thermal Throttling¶

1. Improve Cooling¶

2. Repaste / Replace Thermal Pads¶

3. Undervolt GPU¶

VRAM Allocation Issues¶

Checking Current VRAM Split¶

Issue: Game Crashes with "Out of Memory"¶

Stuttering and Frame Pacing¶

Issue: Inconsistent Frame Times¶

Issue: Video Playback Stutters, Feels Like Slow Internet¶

System Configuration Issues¶

Kernel Parameters (Optimal)¶

Remove nomodeset¶

Performance Monitoring Tools¶

Real-time Monitoring¶

Benchmarking¶

Testing GPU Load on a Headless BC-250¶

Distribution-Specific Issues¶

Fedora¶

Bazzite¶

CachyOS¶

Quick Performance Checklist¶

Getting Help¶

Additional Resources¶