Kernel panic after full system upgrade

MajDan · 2026-03-30 19:07:20

A couple weeks ago, after upgrading, I started getting kernel panic (as indicated by the flashing caps lock LED) on an HP 15-dy1023dx laptop. This happens after selecting the LTS kernel from GRUB and seeing the message about loading the kernel and inital ramdisk. (The main kernel also causes the same kernel panic.)

Running `journalctl -p 0..3 -b -1 -r` shows some ACPI errors. But from reading about this online, I don't think it's related to kernel panic. Please correct me if I'm wrong. I think whatever is causing the issue is crashing the machine before journalctl has a chance to log it.

Mar 30 08:35:39 archlinux kernel: ACPI Error: Aborting method \_SB.PCI0.TXHC.RHUB.SS04._PLD due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
Mar 30 08:35:39 archlinux kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20250807/psargs-332)

(this repeats many, many times)

As a temporary fix, I reverted all packages to their state as of 1 March 2026 by chroot'ing in and downgrading using the Arch Archives https://wiki.archlinux.org/title/Arch_Linux_Archive. The machine runs fine.

I found some articles on the forums related to various causes of kernel panic.

It seems like video, wifi, and thermal control are the most likely culprits. I ran a full system upgrade with `pacman -Syu`. This reintroduced the kernel panic as before. I chroot'd in and blacklisted the following kernel modules, one at a time, by adding `blacklist <module name>` to `/etc/blacklist.conf` and running `mkinitcpio -P`.

rtw88_8821ce
rtw88_8821c
rtw88_core
rtw88_pci
rtw88
snd_sof
snd_hda_intel
i915
processor_thermal_device

Unfortunately, none of these solved the kernel panic. I reverted the system back to 1 March 2026, and it's back to working.

Out of curiosity, I made a Fedora 43 boot disk. It's also producing the same kernel panic. So I think this is not an Arch issue.

Running `lsmod`, there are many modules and dependencies. I suppose I could spend a day blacklisting each of these. I also thought to upgrade one date at a time using the archives to see exactly when the crash started.

Before I do this, I thought I would reach out for any ideas on how to best go about diagnosing this issue.

fastfetch details:
OS: Arch Linux x86_64
Host: HP Laptop 15-dy1xxx
Kernel: Linux 6.12.74-1-lts
Uptime: 32 mins
Packages: 1400 (pacman), 5 (flatpak)
Shell: bash 5.3.9
Display (BOE0897): 1366x768 in 15", 60 Hz [Built-in]
Display (ED320QR S): 1920x1080 in 32", 120 Hz [External]
WM: Sway 1.11 (Wayland)
Cursor: Adwaita
Terminal: alacritty 0.16.1
Terminal Font: JetBrains Mono (10pt, Regular)
CPU: Intel(R) Core(TM) i5-1035G1 (8) @ 3.60 GHz
GPU: Intel Iris Plus Graphics G1 (Ice Lake) @ 1.05 GHz [Integrated]
Memory: 1.69 GiB / 11.44 GiB (15%)
Swap: 0 B / 12.00 GiB (0%)
Disk (/): 26.91 GiB / 31.20 GiB (86%) - ext4
Disk (/home): 54.12 GiB / 189.36 GiB (29%) - ext4
Local IP (wlan0): 10.0.0.137/24
Battery (Primary): 101% [AC Connected]
Locale: en_US.UTF-8

lspci output:
00:00.0 Host bridge: Intel Corporation Ice Lake-LP Processor Host Bridge/DRAM Registers (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G1 (Ice Lake) (rev 07)
00:04.0 Signal processing controller: Intel Corporation Processor Power and Thermal Controller (rev 03)
00:14.0 USB controller: Intel Corporation Ice Lake-LP USB 3.1 xHCI Host Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Ice Lake-LP DRAM Controller (rev 30)
00:15.0 Serial bus controller: Intel Corporation Ice Lake-LP Serial IO I2C Controller #0 (rev 30)
00:15.1 Serial bus controller: Intel Corporation Ice Lake-LP Serial IO I2C Controller #1 (rev 30)
00:16.0 Communication controller: Intel Corporation Ice Lake-LP Management Engine (rev 30)
00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 30)
00:1c.0 PCI bridge: Intel Corporation Ice Lake-LP PCIe Port #8 (rev 30)
00:1d.0 PCI bridge: Intel Corporation Ice Lake-LP PCI Express Root Port #9 (rev 30)
00:1d.2 PCI bridge: Intel Corporation Device 34b2 (rev 30)
00:1f.0 ISA bridge: Intel Corporation Ice Lake-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Ice Lake-LP Smart Sound Technology Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Ice Lake-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller: Intel Corporation Ice Lake-LP SPI Controller (rev 30)
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
02:00.0 Non-Volatile memory controller: Intel Corporation Optane NVME SSD H10 with Solid State Storage [Teton Glacier] (rev 03)
03:00.0 Non-Volatile memory controller: Intel Corporation Optane NVME SSD H10 with Solid State Storage [Teton Glacier]

Thank you.

seth · 2026-03-30 20:02:13

So you moved from 6.12 to 6.18 and that introduced the panic… luckily that narrows it down to only a bazillion kernel commits
https://wiki.archlinux.org/title/Kdump - ideally you can escape from the crashing kernel and obtain a dump from there.

To be sure, you're also not getting a nice BSOD w/ QR code, do you?

loqs · 2026-03-31 02:33:37

You can blacklist the modules from the bootloader to save having to edit a file. If I had to pick a module to start with it would be i915 as it is by far the most complex module of those you listed. As you have tried mainline the next thing to try would be the most recent mainline release candidate:

sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-7.0rc6-1-x86_64.pkg.tar.zst

MajDan · 2026-03-31 12:13:10

seth wrote:

So you moved from 6.12 to 6.18 and that introduced the panic… luckily that narrows it down to only a bazillion kernel commits

True. I get what I deserve, I guess. Thank you for the link to kdumpst.

loqs wrote:

If I had to pick a module to start with it would be i915 as it is by far the most complex module of those you listed.

Blacklisting i915 didn't prevent the panic. I think seth is right, that there are enough commits to last a lifetime.

//

I installed `kdumpst`, enabled and started the service unit. I didn't change any of the values in the config file:

USE_PSTORE_RAM=1
PSTORE_MEM_AMOUNT=4194304
PSTORE_RECORD_SZ=1048576
PSTORE_RAM_USE_CRASH_MEM=0
MOUNT_FOLDER="/var/crash/kdumpst"
FULL_COREDUMP=1
MAKEDUMPFILE_COREDUMP_CMD="-z -d 31"
MAKEDUMPFILE_DMESG_CMD="--dump-dmesg"
KDUMP_APPEND_CMDLINE="panic=-1 oops=panic fsck.mode=force fsck.repair=yes nr_cpus=1 reset_devices initcall_blacklist=drm_core_init module_blacklist=amdgpu,i915,nouveau"
GRUB_AUTOSET=1
GRUB_BOOT_FILE="/boot/grub/grub.cfg"
GRUB_CFG_FILE="/etc/default/grub"
GRUB_CMDLINE="crashkernel=256M "

The journal indicates it's running properly.

$ journalctl -b | grep kdumpst
Mar 31 05:41:07 blackpearl systemd[1]: Starting kdumpst loader boot-time service...
Mar 31 05:41:07 blackpearl root[822]: kdumpst: pstore-RAM was loaded successfully
Mar 31 05:41:07 blackpearl systemd[1]: Finished kdumpst loader boot-time service.

The readme file says running `echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger` as super user should cause a dummy crash and reboot the system. For me, it caused a system freeze but no restart.

From what I read in the same readme file, the crash should have created a log zip file in a `logs` subdirectory.. so /var/crash/kdumpst/logs in my case. The dummy crash test didn't produce this when I checked after a hard reboot.

Running `grep buffer /proc/iomem` gives `00000000-00000000 : RAM buffer`, which I think means the PSTORE_MEM_AMOUNT value in the config file isn't working. Also according to the readme, I could "save PSTORE_MEM_AMOUNT bytes (see the config file) from kernel use
with the "mem=" parameter (requires bootloader configuration)."

Is there an instruction on how to do this?

seth · 2026-03-31 13:01:50

After installing kdumpst, one can check the journal and the following message means kdump is loaded: kdumpst: panic kexec loaded successfully

https://gitlab.freedesktop.org/gpiccoli … heads#L229
But doesn't seem to be the case?

https://wiki.archlinux.org/title/Kdump#Manual_steps
(You might have lost the root partition anyway)

Before that

I started getting kernel panic (as indicated by the flashing caps lock LED) on an HP 15-dy1023dx laptop. This happens after selecting the LTS kernel from GRUB and seeing the message about loading the kernel and inital ramdisk.

and since the panic could happen way too early to step in, see https://wiki.archlinux.org/title/Genera … l_messages
Maybe that can get you more information about the context of the panic.

Does booting the current archlinux installation iso cause a likewise panic?

Arch Linux

#1 2026-03-30 19:07:20

Kernel panic after full system upgrade

#2 2026-03-30 20:02:13

Re: Kernel panic after full system upgrade

#3 2026-03-31 02:33:37

Re: Kernel panic after full system upgrade

#4 2026-03-31 12:13:10

Re: Kernel panic after full system upgrade

#5 2026-03-31 13:01:50

Re: Kernel panic after full system upgrade

Board footer