You are not logged in.

#1 2025-12-27 13:05:05

undeadalex
Member
Registered: 2022-06-28
Posts: 28

Kernel Panicking on AMD System

Panic Report at Crash


This has occurred twice in the last 2-3 hours. Assumably (and hopefully) from updating system today.

System Info:

Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             48 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      12
  On-line CPU(s) list:       0-11
Vendor ID:                   AuthenticAMD
  Model name:                AMD Ryzen 5 7500F 6-Core Processor
    CPU family:              25
    Model:                   97
    Thread(s) per core:      2
    Core(s) per socket:      6
    Socket(s):               1
    Stepping:                2
    Frequency boost:         enabled
    CPU(s) scaling MHz:      77%
    CPU max MHz:             5077.4048
    CPU min MHz:             428.2150
    BogoMIPS:                7400.01
    Flags:                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
                              pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pd
                             pe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology n
                             onstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monito
                             r ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx
                             f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a m
                             isalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_
                             core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 c
                             dp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced
                              vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx5
                             12f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd
                             sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc c
                             qm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx512_bf16 c
                             lzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_loc
                             k nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausef
                             ilter pfthreshold avic vgif x2avic v_spec_ctrl vnmi avx512vbmi um
                             ip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512
                             _bitalg avx512_vpopcntdq rdpid overflow_recov succor smca fsrm fl
                             ush_l1d amd_lbr_pmc_freeze
Virtualization features:
  Virtualization:            AMD-V
Caches (sum of all):
  L1d:                       192 KiB (6 instances)
  L1i:                       192 KiB (6 instances)
  L2:                        6 MiB (6 instances)
  L3:                        32 MiB (1 instance)
NUMA:
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-11
Vulnerabilities:
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Old microcode:             Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Mitigation; Safe RET
  Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitizat
                             ion
  Spectre v2:                Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP al
                             ways-on; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                     Not affected
  Tsa:                       Mitigation; Clear CPU buffers
  Tsx async abort:           Not affected
  Vmscape:                   Mitigation; IBPB before exit to userspace

Storage Configuration:

~> free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi       3.9Gi        55Gi       124Mi       3.3Gi        58Gi
Swap:           15Gi          0B        15Gi
~> lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
zram0       252:0    0 15.6G  0 disk  [SWAP]
nvme0n1     259:0    0  1.9T  0 disk
├─nvme0n1p1 259:1    0  512M  0 part  /boot
└─nvme0n1p2 259:2    0  1.9T  0 part
  └─luksdev 253:0    0  1.9T  0 crypt /var/cache/pacman/pkg
                                      /home
                                      /var/log
                                      /.snapshots
                                      /

System has 64Gb of RAM.

System:

│ kernel-name      │ Linux 
│ kernel-release   │ 6.18.2-arch2-1
│ kernel-version   │ #1 SMP PREEMPT_DYNAMIC Thu, 18 Dec 2025 18:00:18 +0000 
│ machine             │ x86_64 
│ operating-system │ GNU/Linux

Please let me know if any other information would be helpful.

Last edited by undeadalex (2025-12-27 13:06:00)


He was once a man, then he was almost killed, a mob hit gone wrong. Now we can rebuild him, we have the tools, we have FOSS, he will be better. He will be Alex, he will live again!

Offline

#2 2025-12-27 14:22:51

Nikolai5
Member
From: North West, England, UK
Registered: 2024-01-27
Posts: 267

Re: Kernel Panicking on AMD System

I had the same, strange artifacts all over my screen and then the kernel panic screen, unfortunately my Journal has nothing after the panic begins, aside from the lack of shutdown journaling you wouldn't know it had crashed.

I have a Ryzen 7 1800X and an AMD 7800XT.

I have had to revert to 6.18.1 and it is now fine again.
6.18.2 causes a kernel panic as frequent as you said.


Desktop: Ryzen 7 1800X | AMD 7800XT | KDE Plasma

Offline

#3 2025-12-27 14:31:59

loqs
Member
Registered: 2014-03-06
Posts: 18,796

Re: Kernel Panicking on AMD System

Nikolai5 wrote:

I have had to revert to 6.18.1 and it is now fine again.

You could bisect the kernel between 6.18.1 and 6.18.2 to locate the causal commit and report it upstream. Let me know if you need any help with that.

Offline

#4 2025-12-27 15:21:48

Nikolai5
Member
From: North West, England, UK
Registered: 2024-01-27
Posts: 267

Re: Kernel Panicking on AMD System

loqs wrote:

You could bisect the kernel between 6.18.1 and 6.18.2 to locate the causal commit and report it upstream. Let me know if you need any help with that.

Slightly concerned I'm commandeering someone else's topic if their issue is not the same as mine, but yes, I don't mind testing.

I've never done a bisect myself, am I right in saying, that I would git clone the stable kernel from git.kernel.org, start a git bisect, specify good as 6.18.1, bad as 6.18.2 but then I'm not sure what the best way to go about building it is so that it replicates Arch's setup.
Then I install, run, see if it happens and label them as good or bad, rinse and repeat?


Desktop: Ryzen 7 1800X | AMD 7800XT | KDE Plasma

Offline

#5 2025-12-27 15:32:42

loqs
Member
Registered: 2014-03-06
Posts: 18,796

Re: Kernel Panicking on AMD System

I would start with https://aur.archlinux.org/packages/linux-mainline replace

  "$_srcname::git+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#tag=$_tag"

with

  "$_srcname::git+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git#tag=${_tag}?signed"

Use the kernel config from https://gitlab.archlinux.org/archlinux/ … ef8/config which is the commit for 6.18.2.arch2-1.
Update the checksums then the rest is as you have outlined.

Offline

#6 2025-12-27 16:45:12

Nikolai5
Member
From: North West, England, UK
Registered: 2024-01-27
Posts: 267

Re: Kernel Panicking on AMD System

Thanks, I'll give that a go, obviously it involves recompilations and testing, so it'll take a bit of time, I'll report back when I can.

@OP Have you found that version 6.18.1 is stable for you?


Edit2: Resolved build issue, just needed to manually make olddefconfig, will see if it anything comes of this, there's no defined (that I know of) trigger for the panic. I still recommend OP doing the same thing as well.

Last edited by Nikolai5 (2025-12-27 17:50:38)


Desktop: Ryzen 7 1800X | AMD 7800XT | KDE Plasma

Offline

#7 2025-12-28 03:50:07

undeadalex
Member
Registered: 2022-06-28
Posts: 28

Re: Kernel Panicking on AMD System

loqs wrote:
Nikolai5 wrote:

I have had to revert to 6.18.1 and it is now fine again.

You could bisect the kernel between 6.18.1 and 6.18.2 to locate the causal commit and report it upstream. Let me know if you need any help with that.


I am happy to do this as well. I was pondering how to do that. Would like to report upstream. Will review your link, please let me know if there are any further steps, and also where do you open an issue upstream?


He was once a man, then he was almost killed, a mob hit gone wrong. Now we can rebuild him, we have the tools, we have FOSS, he will be better. He will be Alex, he will live again!

Offline

#8 2025-12-28 03:51:08

undeadalex
Member
Registered: 2022-06-28
Posts: 28

Re: Kernel Panicking on AMD System

Nikolai5 wrote:

Thanks, I'll give that a go, obviously it involves recompilations and testing, so it'll take a bit of time, I'll report back when I can.

@OP Have you found that version 6.18.1 is stable for you?


Edit2: Resolved build issue, just needed to manually make olddefconfig, will see if it anything comes of this, there's no defined (that I know of) trigger for the panic. I still recommend OP doing the same thing as well.

Different timezone than you I suspect. Just logged on for the day. Will update later after rolling back.

EDIT: I let my desktop run for the last few hours with regular use and still haven't had a panic. I have not rolled back. Will update if I get a crash and then roll back.

Last edited by undeadalex (2025-12-28 07:00:59)


He was once a man, then he was almost killed, a mob hit gone wrong. Now we can rebuild him, we have the tools, we have FOSS, he will be better. He will be Alex, he will live again!

Offline

Board footer

Powered by FluxBB