AMDGPU SecureDisplay Query Failed Ret 0x0 | Fix Steps

Guide / By

That log line usually means the AMD GPU’s secure display trusted applet didn’t answer; if your screen works, you can often ignore it.

You’ll usually spot AMDGPU SecureDisplay Query Failed Ret 0x0 during boot, resume, logout, or a warm reboot. Sometimes it shows up once, then your desktop loads and life goes on. Other times it pairs with a blank panel on battery, a flickering external monitor, or a login screen that never appears.

This article helps you sort those two cases fast, then apply fixes that fit your setup. It sticks to practical checks you can run in a few minutes, plus deeper steps when you’re still stuck at a black screen.

What This Message Is Trying To Say

On modern AMD GPUs, some display features run through the Platform Security Processor (PSP). Secure Display is one of those features. The driver talks to a small trusted applet (often shown as a “TA” in logs) and asks it questions during setup and power events.

When you see “query failed,” the driver asked the applet for a status and didn’t get a usable answer. The confusing bit is ret 0x0, which can appear even when the system runs fine.

So, treat the log line as a clue, not a verdict. The next step is to decide whether you have a real display or stability problem tied to the same moment in the log.

AMDGPU SecureDisplay Query Failed Ret 0x0 During Boot

This is the spot most people notice it. A burst of amdgpu messages hits in the boot journal. You may also see PSP lines such as LOAD_TA or INVOKE_CMD right before it. Some laptops show it more on battery than on AC power, and warm reboots can fail more often than cold starts.

Keeping a note of when it appears makes later troubleshooting faster and calmer.

What You See What It Often Means First Thing To Try
Message shows once, desktop loads Benign log noise on your firmware/kernel combo Update system packages and keep notes
Blank screen on battery, works on AC Runtime power change trips the display init path Test amdgpu.runpm=0
Warm reboot fails, cold boot works GPU doesn’t re-init cleanly after power state change Update BIOS and linux-firmware
External monitor drops or flickers Link training issue near a power or display event Try a newer kernel and Mesa
Hard freeze under graphics load Separate amdgpu fault; secure display line may be a bystander Grab logs and check for ring timeouts

If your system is stable and the screen behaves, you can treat the message as a low-priority annoyance. If your screen fails to light up, or it flips between working and not working based on power source, keep reading and run the quick checks first.

Fast Checks To Sort Noise From A Real Fault

Start by confirming whether the message is isolated or part of a larger chain. You’re looking for timing: does the failure line sit right next to your black screen event, suspend event, or display hotplug event?

  • Find The Boot Window — Run journalctl -b -k | grep -i -E 'amdgpu|securedisplay|psp' and scroll around the first occurrence.
  • Match It To Symptoms — Note the timestamp of the blank screen, flicker, or login hang, then compare it to the log burst.
  • Check Your GPU Path — Run lspci -nnk | grep -A3 -E 'VGA|Display' and confirm the kernel driver in use is amdgpu.
  • Confirm Firmware Packages — Verify your distro’s linux-firmware (or equivalent) package is installed and up to date.
  • Rule Out A One-Off Glitch — Do one cold boot after a full shutdown, not a reboot, then see if the line repeats.

If the secure display line shows up with no follow-on errors and the desktop loads, it’s fine to park it for later. If the line sits beside repeated PSP failures, display init errors, or a hang, the next sections are worth your time.

Fixes That Usually Clear The Error Or The Symptoms

Most lasting fixes land in one of three buckets: firmware, kernel/Mesa, or power behavior. Try them in that order so you change one variable at a time.

Bring BIOS And Firmware Up To Date

Secure Display rides on firmware. If your BIOS is old, the PSP firmware and platform tables can lag behind what newer kernels expect. A BIOS update can change how power states behave on battery and during warm reboots.

  • Update BIOS From The Vendor — Use the vendor’s method (UEFI tool, Windows flasher, or Linux capsule update if your model provides it).
  • Update OS Firmware Bits — Install the latest linux-firmware package and reboot after the update.
  • Power Cycle Once — Shut down, unplug for a minute, then boot again to reset platform state.

Move To A Kernel And Mesa Pair That Matches Your GPU

amdgpu and Mesa move fast. Newer chips often need newer kernels, and older chips can hit regressions that get fixed a few releases later. If your distro offers multiple kernels (mainline and LTS), test both.

  • Install A Newer Kernel — Use your distro’s mainline or hardware enablement kernel, then reboot and retest.
  • Try An Older Kernel — If the issue began after an update, boot the previous kernel from your boot menu.
  • Update Mesa Userspace — Keep Mesa and Vulkan drivers aligned with your distro’s packages.

Tame Runtime Power Changes On Laptops

A common pattern is “works on AC, fails on battery.” That points to runtime power management. Many users report better boot reliability by disabling run-time power management for amdgpu.

  • Try A One-Time Kernel Arg — Add amdgpu.runpm=0 to your kernel command line, boot once, and test the same scenario.
  • Make It Persistent — If it helps, keep it in GRUB (or your bootloader config) and regenerate the boot config.
  • Undo It If You Don’t Need It — Disabling runpm can raise idle power draw, so keep it only if it solves a real problem.

You may find old advice that says to disable secure display with amdgpu.securedisplay=0. On some newer kernels, that option is ignored, and it may not appear in current module parameter docs. If your kernel doesn’t accept it, stick with the fixes above.

Check Secure Boot And Extra Driver Stacks

Secure Display errors can show up on machines where the real issue is that the amdgpu module or a related piece did not load the way you think it did. This comes up most often with Secure Boot plus DKMS modules, or with mixed graphics stacks pulled from different repos.

  • Check Secure Boot Status — Run mokutil --sb-state to see whether Secure Boot is on.
  • Confirm The Module Loaded — Run lsmod | grep -E "^amdgpu" and confirm the driver is present.
  • Check For Module Errors — Run journalctl -b -k | grep -i -E "amdgpu|taint|module|signature" and look for signature or load failures.
  • Avoid Mixed Driver Sources — If you installed AMDGPU-PRO or a third-party Mesa build, revert to your distro’s stock packages for a clean test.
  • Rebuild After Kernel Changes — If you use DKMS, re-run its rebuild step after a kernel update so the module matches the running kernel.

Test Docks, Adapters, And External Displays

If the issue shows up only with an external monitor or a USB-C dock, boot with one screen, then add pieces back. A different link path can change display init timing.

  • Boot With One Screen — Disconnect all externals, boot, then plug a monitor after login.
  • Swap The Path — Try HDMI vs DisplayPort, or a different dock port, to change the link path.
  • Skip Adapters For A Test — Remove DP-to-HDMI adapters and long cables and try a direct cable.
  • Turn Off Deep Sleep Modes — In BIOS, disable vendor “deep sleep” or aggressive power savings tied to external ports, then retest.

If You’re Stuck With A Black Screen Or Login Loop

If the screen never comes up, you need a path into the system first. Once you can log in, you can update packages and test changes without guessing.

Get A Boot That Reaches A Shell

  • Pick An Older Kernel — From the boot menu, choose the previous kernel and see if graphics return.
  • Disable Quiet Splash — Remove quiet and splash options so you can see where boot stops.
  • Use A Text Console — Try Ctrl + Alt + F3 to reach a TTY and log in.
  • Boot With Nomodeset — As a last resort, add nomodeset to reach a basic display path, then fix the real driver stack.

Repair The Graphics Stack Once Logged In

Once you’re in, aim for a clean, consistent driver stack. That usually means kernel, firmware, and Mesa from the same repo set.

  • Update Everything — Run your distro’s full update, then reboot into the updated kernel.
  • Reinstall Firmware — Reinstall the linux-firmware package to undo a partial update or a bad mirror.
  • Rebuild Initramfs — Regenerate initramfs so the right firmware and modules load at boot.
  • Remove Extra Driver Stacks — If you installed AMDGPU-PRO or mixed repos, revert to a single source for amdgpu and Mesa.

If you use DKMS-based driver stacks under Secure Boot, kernel modules may need signing to load. A driver that fails to load cleanly can leave you with a blank screen, and the secure display log line can show up as collateral.

Log Bundle To Share When You Need A Fix Upstream

If the issue is repeatable, a good log bundle saves days of back-and-forth. It also helps maintainers match your report to known issues, like battery-only boot failures or warm reboot failures tied to PSP calls.

  • Capture Kernel Logs — Save dmesg -T output from a failing boot and from a working boot.
  • Capture Boot Journal — Save journalctl -b -k plus journalctl -b for userspace context.
  • Record Hardware Info — Include lspci -nnk, lsusb, and inxi -Fz if available.
  • Record Versions — Note kernel version, Mesa version, linux-firmware version, and BIOS version.
  • Describe The Trigger — Write the exact steps that lead to failure: cold boot on battery, warm reboot, suspend then resume, dock attach, or external monitor plug.

When you file the report, start with your distro’s tracker if the bug appears after an update. If the issue reproduces across distros on the same kernel, you may also file it on the upstream amdgpu DRM tracker. Include the log lines around AMDGPU SecureDisplay Query Failed Ret 0x0, plus the PSP lines above it, and attach both the “good boot” and “bad boot” logs.

Once you have a stable boot, you can also watch later kernel and firmware updates. Many of these glitches get fixed quietly in later releases, and a simple kernel hop can end the whole saga.