BIOS F.79 appears to have broken Linux AMDGPU/KMS graphics on HP 15s-eq0003nv (board 86FD)

[petrichorchair]

Hello,

I am having a graphics/boot problem on an HP Laptop 15s-eq0003nv that appears to have started immediately after a BIOS update to F.79.

Hardware

Model: HP Laptop 15s-eq0003nv

Product number: 8RU92EA

Motherboard / board ID: 86FD

CPU: AMD Ryzen 5 3500U

Integrated GPU: AMD Radeon Vega 8 / Picasso / Raven 2

BIOS vendor: AMI

Current BIOS: F.79

BIOS release date reported by the system: 04/16/2026

ROM size: 16 MB

The laptop dual-boots Windows and Kubuntu Linux.

When the problem started

After updating the BIOS to F.79, Kubuntu stopped booting normally.

Before the BIOS update, this Kubuntu installation worked normally.

Windows continues to work, but normal Kubuntu graphics boot no longer works.

Exact Linux symptom

With a normal Linux boot, the kernel starts and then I get:

"RDRAND is not reliable on this platform; disabling."

After that the screen becomes black/dark.

A mouse cursor can initially be moved around, but then the screen becomes a brighter black and the Linux mouse cursor repeatedly disappears and reappears. Every time it reappears it is teleported back toward the center of the screen.

The graphical login/desktop never becomes usable.

Ctrl+Alt+F3 does not give me a usable text console.

Important workaround

Kubuntu boots successfully when I add:

nomodeset

to the kernel command line.

The working boot uses:

Linux kernel 7.0.0-30-generic

and:

root=/dev/nvme0n1p6 ro nomodeset

This strongly suggests the failure is related to normal graphics modesetting.

Kernel testing

I have two installed kernels:

7.0.0-30-generic

7.0.0-31-generic

Both show the same black-screen problem when booted normally without nomodeset.

So this does not appear to be specific to only one installed Linux kernel.

GPU detection

The GPU is detected as:

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev c2)

The AMDGPU driver does NOT simply fail to load.

The kernel log shows AMDGPU initializing kernel modesetting and successfully proceeding through most of the GPU initialization.

Relevant messages include:

amdgpu 0000:04:00.0: initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x103C:0x86FD 0xC2)

amdgpu 0000:04:00.0: Fetched VBIOS from VFCT

amdgpu 0000:04:00.0: [drm] ATOM BIOS: 113-PICASSO-117

amdgpu 0000:04:00.0: [drm] VRAM: 2048M

amdgpu 0000:04:00.0: [drm] 4926M of GTT memory ready

amdgpu 0000:04:00.0: [VCN instance 0] Found VCN firmware

There is one notable PSP error:

psp gfx command LOAD_TA(0x1) failed and response status is (0x7)

However, the driver continues initializing after this.

Most importantly, the kernel eventually reports:

amdgpu 0000:04:00.0: [drm] Display Core v3.2.369 initialized on DCN 1.0

amdgpu 0000:04:00.0: [drm] Initialized amdgpu 3.64.0 for 0000:04:00.0

fbcon: amdgpudrmfb (fb0) is primary device

amdgpu 0000:04:00.0: [drm] fb0: amdgpudrmfb frame buffer device

So the AMDGPU driver appears to initialize successfully before the graphical display failure.

KWin / DRM failure

Immediately around the display failure, SDDM/KWin reports:

kwin_wayland_drm: Received unexpected add udev event for: "/dev/dri/card0"

kwin_wayland_drm: Atomic modeset test failed! No such device

KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: No such device

kwin_core: Applying output configuration failed!

kwin_core: Failed to open /dev/dri/renderD128 device (No such device)

kwin_wayland_drm: Failed to open drm device /dev/dri/renderD128

kwin_wayland_drm: Primary gpu has been removed! Quitting...

kwin_core: Failed to find a working output layer configuration!

The Wayland greeter then loses its connection:

"The Wayland connection broke. Did the Wayland compositor die?"

SDDM repeatedly restarts the greeter.

This looks like the DRM GPU device is changing/disappearing during the transition from the kernel framebuffer/AMDGPU initialization to the graphical compositor.

SDDM / Wayland investigation

I found an SDDM configuration file that explicitly forced Wayland:

/etc/sddm.conf.d/10-wayland.conf

It contained:

[General]

DisplayServer=wayland

GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell

[Wayland]

CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1

I renamed this file to:

10-wayland.conf.disabled

I also tested explicitly forcing X11 instead of Wayland.

This did NOT solve the underlying problem.

With the working nomodeset boot, I can use an X11 Plasma session successfully.

However, normal AMDGPU/KMS boot still fails.

Therefore I do not believe this is simply a Wayland configuration problem.

HP WMI test

The kernel also reports HP WMI / ACPI firmware errors, including:

hp-wmi ... Failed to apply initial fan settings: -22

and multiple ACPI errors such as:

ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT

ACPI Error: Aborting method _SB.WMID.WQBZ

ACPI Error: Aborting method _SB.WMID.WQBE

ACPI Error: Aborting method \HWMC

ACPI Error: Aborting method _SB.WMID.WMAA

I tested unloading/blacklisting hp_wmi.

That did NOT fix the normal graphics boot.

Therefore hp_wmi does not appear to be the sole cause.

initramfs test

I also tested whether this was caused by AMDGPU loading too late.

Initially, amdgpu.ko was not present in the initramfs for kernel 7.0.0-30.

I added:

amdgpu

to:

/etc/initramfs-tools/modules

and rebuilt the initramfs with:

sudo update-initramfs -u -k 7.0.0-30-generic

I verified that amdgpu.ko was then present in the initramfs.

The machine was rebooted and tested again without nomodeset.

The result was unchanged: RDRAND warning followed by the same black/flickering display problem.

So early-loading AMDGPU into the initramfs did not resolve the issue.

BIOS recovery / rollback

I also tried HP BIOS recovery using the Win+B + Power procedure.

It simply restored BIOS F.79 again.

During the original BIOS update process, the HP BIOS installer also indicated that, for security reasons, rollback to previous BIOS versions was not allowed.

I therefore have NOT attempted to force-flash an older BIOS.

Why I suspect the BIOS

The problem appeared immediately after updating to BIOS F.79.

The current BIOS reports:

Version: F.79

Release Date: 04/16/2026

The Linux failure is specifically connected to normal AMDGPU/KMS initialization, while nomodeset continues to provide a working Linux system.

The kernel also reports the RDRAND reliability warning, several ACPI/WMI firmware errors, and an AMD PSP LOAD_TA failure.

The GPU subsequently initializes, but when KWin takes over DRM it reports that the primary GPU has disappeared / the DRM device is unavailable.

Because the failure began with the BIOS update and because the Linux graphics stack works when normal modesetting is disabled, I am concerned that F.79 may contain a firmware regression or a compatibility problem with this AMD Picasso/Vega platform.

What I would like HP to confirm

Please check this exact machine and board:

HP 15s-eq0003nv

Product number 8RU92EA

Board ID 86FD

I would like to know:

1. Is BIOS F.79 officially intended for this exact 8RU92EA / 86FD system?

2. Is there a known issue in F.79 involving AMD Radeon Vega / Picasso graphics, DRM/KMS, Linux, ACPI/WMI, or GPU initialization?

3. Is there a newer BIOS that fixes this problem?

4. If F.79 is responsible, is there an HP-supported method to revert this exact machine to the previous known-good BIOS despite the downgrade restriction?

5. If normal rollback is intentionally blocked, is there an official recovery image or HP-supported procedure specifically for this machine?

I am not looking for generic advice to reinstall Linux or reinstall the AMD graphics driver. The Linux installation worked before the BIOS update, and the AMDGPU driver successfully initializes. The failure is occurring during the graphics/DRM handoff.

I can provide additional Linux journal logs if needed.

Thank you.

[petrichorchair]

UPDATE — SOLVED ON MY MACHINE I continued troubleshooting and found a working solution. The important discovery was that this was not primarily an SDDM, Wayland, X11, or "hp_wmi" problem. On a failed normal boot, the kernel showed: simpledrm ... Initialized simpledrm ... on minor 0 followed later by AMDGPU: amdgpu ... initializing kernel modesetting (RAVEN ...) ... [drm] Initialized amdgpu 3.64.0 for 0000:04:00.0 on minor 1 fbcon: amdgpudrmfb (fb0) is primary device So "simpledrm" had claimed DRM "card0" before AMDGPU initialized and took "card1". At the same time, KWin/SDDM reported: kwin_wayland_drm: Atomic modeset test failed! No such device KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: No such device kwin_core: Applying output configuration failed! kwin_core: Failed to open /dev/dri/renderD128 device (No such device) kwin_wayland_drm: Failed to open drm device /dev/dri/renderD128 kwin_wayland_drm: Primary gpu has been removed! Quitting... I tested several possible causes: - Booting kernel 7.0.0-30 normally — failed. - Booting kernel 7.0.0-31 normally — failed. - "nomodeset" — worked, confirming the problem was related to normal graphics modesetting. - Removing the SDDM Wayland configuration / using X11 — did not fix normal KMS boot. - Blacklisting "hp_wmi" — did not fix it. - Adding "amdgpu" to the initramfs and rebuilding it — did not fix it. - BIOS recovery using Win+B — simply restored F.79. The key test was adding this temporary kernel parameter: initcall_blacklist=simpledrm_platform_driver_init without "nomodeset". That immediately allowed the system to boot normally into Plasma. I then made the parameter permanent in "/etc/default/grub": GRUB_CMDLINE_LINUX_DEFAULT="quiet splash initcall_blacklist=simpledrm_platform_driver_init" and ran: sudo update-grub After rebooting normally, including with kernel 7.0.0-31-generic, the system booted successfully into the graphical desktop. I also verified: cat /proc/cmdline returns: ... initcall_blacklist=simpledrm_platform_driver_init and: ls -l /dev/dri/ now shows: card0 renderD128 instead of the failed-boot situation where simpledrm occupied "card0" and AMDGPU became "card1". Why I believe this is the actual cause I found an upstream report from March 2026 titled: “drm/simpledrm: no handoff to amdgpu on Picasso/Raven2” It describes extremely similar behavior on AMD Picasso/Raven2 hardware: - simpledrm registers as DRM minor 0 / "card0" - amdgpu loads later and becomes minor 1 / "card1" - the desktop compositor selects "card0" - DRM operations return "ENODEV" / “No such device” - the graphical session crashes This is very close to what happened on my machine. Upstream report: https://www.mail-archive.com/dri-devel%40lists.freedesktop.org/msg595802.html A detailed reproduction/workaround for the same class of problem is also documented here: https://github.com/jillravaliya/amdgpu-simpledrm-driver-conflict That project reports the same basic workaround: initcall_blacklist=simpledrm_platform_driver_init which causes AMDGPU to become "card0" instead of "card1". Hardware HP Laptop 15s-eq0003nv Product number: 8RU92EA Board ID: 86FD CPU: AMD Ryzen 5 3500U GPU: AMD Radeon Vega / Picasso / Raven2 BIOS: F.79 BIOS date reported by DMI: 04/16/2026 BIOS observation This problem started immediately after updating the laptop BIOS to F.79. The F.79 BIOS also produces the Linux warning: RDRAND is not reliable on this platform; disabling. and there are several ACPI/WMI firmware errors. I am therefore still interested in knowing whether BIOS F.79 changed something related to the display initialization/firmware configuration on this model. However, the immediate Linux graphics problem is now reproducibly worked around by preventing simpledrm from registering. Practical workaround For other AMD Picasso/Raven2 systems experiencing the same symptoms, the kernel parameter to test is: initcall_blacklist=simpledrm_platform_driver_init If it works, it can be added to: /etc/default/grub for example: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash initcall_blacklist=simpledrm_platform_driver_init" followed by: sudo update-grub and a reboot. This worked for me on the HP 15s-eq0003nv.