Category: Ubuntu Linux

[ Dec 2025 Update ] If you’re running an AMD Ryzen laptop on Linux ( Ubuntu ) and noticed your CPU is stuck at base clock speeds after waking from suspend, you’re not alone. This is a known bug with the amd-pstate-epp driver that affects many Ryzen mobile processors.

Background: The BIOS Frequency Cap Problem

Many AMD Ryzen laptops (especially ASUS models) have BIOS-imposed power limits that prevent the CPU from reaching its full boost frequency. The default acpi-cpufreq driver respects these limits, leaving you stuck at lower clocks.

The fix is to use the amd-pstate driver with kernel parameters that bypass these limits:

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_pstate=active processor.ignore_ppc=1 acpi_cpufreq.enable_pcc=false intel_pstate=disable"

What these do:

• amd_pstate=active – Use AMD’s modern pstate driver in autonomous mode
• processor.ignore_ppc=1 – Ignore BIOS _PPC power performance control limits
• acpi_cpufreq.enable_pcc=false – Disable Platform Communication Channel limits
• intel_pstate=disable – Prevent Intel driver from loading (AMD system)

After adding these, run sudo update-grub and reboot.

This gets your CPU boosting to full speed on fresh boot. But then comes the suspend bug…

The Problem

After resuming from suspend, my AMD Ryzen 7 4800H was locked at 2.9 GHz instead of boosting to its full 4.3 GHz. The system felt sluggish, and checking the frequencies confirmed the issue:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2901000

That’s 2.9 GHz – the base clock. The CPU should be capable of:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
4300902

4.3 GHz boost was completely unavailable after suspend.

Diagnosis

The culprit is the amd-pstate-epp driver running in “active” mode:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
amd-pstate-epp

$ cat /sys/devices/system/cpu/amd_pstate/status
active

In active mode, the hardware autonomously manages frequency scaling. After suspend, something breaks in this handoff and the driver fails to restore the full frequency range.

What Doesn’t Work

• Writing directly to scaling_max_freq – ignored by the driver
• Toggling CPU boost off/on
• Cycling power profiles
• Restarting power-profiles-daemon
• Using cpupower commands

The Solution

The fix is surprisingly simple: cycle the amd-pstate mode from active to passive and back:

echo passive | sudo tee /sys/devices/system/cpu/amd_pstate/status
sleep 1
echo active | sudo tee /sys/devices/system/cpu/amd_pstate/status

This forces the driver to reinitialize and properly restore the frequency limits.

Making It Permanent

Create a script that runs automatically after resume:

sudo tee /lib/systemd/system-sleep/cpu-freq-restore << 'EOF'
#!/bin/bash
case $1 in
  post)
    # Fix amd-pstate-epp bug after resume
    /usr/bin/echo passive > /sys/devices/system/cpu/amd_pstate/status 2>/dev/null
    /bin/sleep 1
    /usr/bin/echo active > /sys/devices/system/cpu/amd_pstate/status 2>/dev/null

    # Set performance EPP
    for epp in /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference; do
      /usr/bin/echo performance > "$epp" 2>/dev/null
    done
    ;;
esac
exit 0
EOF

sudo chmod 755 /lib/systemd/system-sleep/cpu-freq-restore

Scripts in /lib/systemd/system-sleep/ are automatically executed by systemd:

• On suspend: called with pre argument
• On resume: called with post argument

The script runs as root, so no authentication prompts will appear.

Verification

After your next suspend/resume cycle, verify the fix:

# Check max frequency is restored
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
4300902

# Check actual frequencies (should see boost clocks under load)
$ grep "MHz" /proc/cpuinfo | head -4
cpu MHz        : 4290.553
cpu MHz        : 4270.657
cpu MHz        : 4290.130
cpu MHz        : 1113.175

Why This Happens

The amd-pstate-epp driver in “active” mode relies on the CPU’s internal firmware (CPPC – Collaborative Processor Performance Control) to manage frequencies. During suspend, the CPU state is saved, but on resume, the CPPC negotiation between the OS and firmware doesn’t properly restore the upper frequency limits.

Cycling through “passive” mode forces a complete reinitialization of the driver’s frequency tables, which correctly queries the hardware capabilities again.

Affected Systems

This bug appears to affect:

• AMD Ryzen 4000/5000/6000/7000 series mobile processors
• Linux kernels with amd-pstate-epp driver (5.17+)
• Systems using amd_pstate=active kernel parameter
• ASUS laptops with restrictive BIOS power limits (ROG, TUF, Zephyrus series)

The Full Picture

If you have an AMD Ryzen laptop that won’t boost properly, you likely need both fixes:

1. Kernel parameters (in /etc/default/grub) – to bypass BIOS limits on boot
2. Resume script (in /lib/systemd/system-sleep/) – to restore frequencies after suspend

Without the kernel parameters, you’re stuck at base clock all the time. Without the resume script, you lose boost after every suspend cycle.

Alternative: Use Passive Mode Permanently

If you prefer, you can run in passive mode permanently by adding to your kernel parameters:

amd_pstate=passive

In passive mode, the OS has more direct control over frequency scaling, and the suspend bug doesn’t occur. However, active mode generally provides better power efficiency when working correctly.

Tested on ASUS TUF Gaming A17 (FA706IC) with AMD Ryzen 7 4800H, running Ubuntu 25.10 and kernel 6.18.1

How to Make the TP-Link Archer TX50Uh AX3000 USB WiFi Adapter Work on Ubuntu?

If you recently bought the TP-Link Archer TX50Uh AX3000 Wireless USB Adapter from Amazon India and discovered it doesn’t work out of the box on Ubuntu Linux, you’re not alone.

Here’s how I got it working smoothly on my Ubuntu system. ( Tested on the Newest Ubuntu 25.04 -when writing )

Amazon Product package: Tp-Link Archer Tx50Uh Ax3000 High Gain Wireless USB Adapter | 3000 Mbps Dual Band WiFi 6 | High Gain Antennas and Beamforming | USB 3.0 | Wpa3 | Ofdma and Mu-Mimo – Black

This device in lsusb shows up as ID 35bc:0101 Realtek 802.11ax WLAN Adapter.

It’s quite easy to make it work on Ubuntu. Here are the steps.

1. Install Required Packages

Open a terminal and run:

sudo apt update
sudo apt install -y build-essential dkms git linux-headers-$(uname -r)

2. Clone the Correct Driver Repository

Thanks to morrownr for maintaining a reliable driver repo for this chipset.

git clone https://github.com/morrownr/rtl8852cu-20240510
cd rtl8852cu-20240510

3. Build and Install the Driver

make
sudo make install

4. Configure the Module

During installation, a config file will open in nano. Find this line:

options 8852cu rtw_switch_usb_mode=0

Change it to:

options 8852cu rtw_switch_usb_mode=1

Save and exit (Ctrl+O, Enter, Ctrl+X).

To edit this config later, you can find it at:

sudo nano /etc/modprobe.d/8852cu.conf or use Vi or gedit

5. Reboot and Connect

Now reboot your system:

sudo reboot

After rebooting, your TP-Link WiFi adapter should be detected. The LED should start blinking, and you should see WiFi networks available in your settings.

Enjoy browsing the Interwebs.on your Ubuntu 🙂

When working with external monitors on Ubuntu, adjusting the brightness of the external monitor connected to your laptop can often be a challenge, especially when traditional methods fail or when you’re working with specific hardware like NVIDIA GPUs or USB-C to HDMI adapters. Many users struggle with issues such as brightness settings not being adjustable or xrandr and ddcutil commands failing, even when everything seems to be set up correctly.

After installing the latest Ubuntu 25.04 Plucky Puffin, I found myself in a similar situation where my external monitor’s brightness was already at its lowest, yet it was still too bright for many users, leading to frustration. In this guide, we will explore multiple ways to adjust the brightness of your external monitor on just-launched Ubuntu 25.04 and add a special focus on the Xorg solution—an option that could save the day when everything else fails.

( Skip to Method 3 if you want a simple solution – Also check that Bonus Github Script )

Method 1: Using xrandr (Basic Brightness Control)

One of the most common methods to adjust brightness on Ubuntu is through xrandr, which allows users to manipulate various display properties directly from the terminal. For external monitors, you can try the following:

xrandr --output HDMI-A-0 --brightness 0.7

However, xrandr’s --brightness option has limited effectiveness, especially for certain monitors and drivers. It doesn’t directly change the hardware brightness but simulates brightness by adjusting the display’s gamma, which may not always work as expected.

It also usually doesn’t work these days on Ubuntu Wayland versions.

Method 2: Using ddcutil (DDC/CI Communication)

If you need to adjust hardware brightness (as in the actual brightness level controlled by the monitor), ddcutil is a great tool, provided your monitor supports DDC/CI (Display Data Channel/Command Interface). You can install it using the following command:

sudo apt install ddcutil

Once installed, you can attempt to adjust the brightness using ddcutil:

ddcutil setvcp 0x10 50

Unfortunately, this method doesn’t always work due to compatibility issues between the software, the monitor, and the connection type (such as USB-C to HDMI). You might encounter errors like:

DDCRC_READ_ALL_ZERO

Method 3: Switching to Xorg (A Potential Solution)

If traditional methods like xrandr and ddcutil fail, switching to Xorg could be a game-changer. By default, many modern Ubuntu systems use Wayland as the display server. However, Xorg might offer better compatibility with certain monitors, especially when it comes to adjusting external monitor brightness.

Why Switch to Xorg?

• Better compatibility with legacy hardware and drivers.
• Improved handling of external monitors and DDC/CI.
• If your external monitor is not behaving as expected under Wayland, switching to Xorg can help address issues related to brightness control.

How to Switch to Xorg ( Recommended APproach )

Switching to Xorg on Ubuntu is simple. Follow these steps:

1. Log Out from your current session.
2. On the login screen, click on the gear icon (⚙️) down in the bottom right corner and select Ubuntu on Xorg.
3. Log back in.

Alternatively, if you want to make Xorg the default display server:

1. Edit the GDM configuration file: sudo nano /etc/gdm3/custom.conf
2. Uncomment (remove the #) the line that says WaylandEnable=false.
3. Save and exit the file, then reboot your system: sudo reboot

After switching to Xorg, you should see improved compatibility with xrandr, ddcutil, and other display tools, particularly for external monitors.

What Worked After Switching to Xorg

After switching to Xorg, I found that the xrandr command worked properly, but I had to first determine the correct monitor identifier. I used the following command to list all connected monitors:

xrandr | grep connected

This showed me the monitor I needed to target. Once I had the correct output identifier, I was able to adjust the brightness successfully:

xrandr --output HDMI-A-0 --brightness 0.7

Additionally, I found that xgamma could be used to adjust the gamma of the display. This is useful for fine-tuning the color and brightness in a different way, though it’s more of a gamma correction tool rather than a direct brightness control. To adjust the gamma, you can use the following command:

xgamma -display :0 -gamma 0.5

This command adjusts the gamma to 0.5, effectively darkening the screen (or brightening, depending on the value). While it doesn’t directly control the monitor’s brightness, it’s a good option for tweaking the overall appearance.

Persisting xrandr and xgamma Settings Across Reboots

Unfortunately, both xrandr and xgamma settings are temporary and will not survive a reboot or logout by default. When you log out or reboot, the display settings are reset, and you’ll need to reapply them after logging in again.

Workaround for Persistence:

To make these settings persist across reboots or logouts, you can create a startup script to automatically apply the settings when you log in. Here’s how you can do it:

1. Open a terminal and create a new script file: vi ~/set_display_brightness.sh
2. Add the xrandr and/or xgamma commands to this script. For example: #!/bin/bash
xrandr --output HDMI-A-0 --brightness 0.7
   You have to find your monitor name by running the command xrandr | grep connected ( For me, it’s HDMI-A-0 ) – WARNING – Don’t use 0 as the brightness value – your screen will go Black.
3. Save the file and close the editor.
4. Make the script executable: chmod +x ~/set_display_brightness.sh

Set the Script to Run on Startup

You can configure Ubuntu to run this script automatically when you log in:

1. Press Alt + F2, type gnome-session-properties, and press Enter to open the Startup Applications Preferences.
2. In the Startup Applications Preferences, click Add to add a new startup program.
3. In the Name field, enter something descriptive, such as Set Display Brightness.
4. In the Command field, enter the full path to the script, like: /home/yourusername/set_display_brightness.sh
5. Click Add, then Close.

Now, each time you log in, the script will run automatically and set your brightness settings to your preferences.

BONUS: A Bash Script to Create a System Tray Icon to Adjust Brightness ( for Ubuntu on Xorg only ) – Github link.

Save your eyes.