Kernel Panic and system freezes with 4x16 DDR5

qxbash · 2026-05-11 16:55:23

I recently added an additional two sticks of ddr5 ram to my system, and it has been a complete nightmare.

I initially figured out it was the ram since this never happened when I was running two. My motherboard simply rejects either AMD EXPO profile both 6000 and 5600 and freezes, in which I need to reset CMOS to gain access.

After disabling expo the system does run for a while, but it will crash at random times, kernel panic error statements vary slightly as it failed to end a specific service. Sometimes there is no kernel panic and just a system freeze, which I suspected was the GPU but ended up dismissing it after appending amdgpu.ppfeaturemask=0xffff7fff or its variants to systemd-boot kernel entries (not silencing the issue). The default non-EXPO speeds for 2 sticks is 4800 and 3600 for 4, which my computer crashes even at base speeds. 'Memory Try It!" still causes crashes but boot at the lowest 5600 preset even though EXPO 5600 preset doesn't. I proceeded to manually change the dram speeds to 5400, 5200, 5000, 4800, respectively and they all still crash within 30min-2hrs of uptime. I have not messed with the dram voltage or timings for these tests (outside of 'Memory Try It!' presets) just the dram speeds.

I switched between Hyprland and KDE Plasma, and the crashes still persisted between the two.

I also test both the current zen kernel and cachyos kernel and they both still crash

I ran memtest86+ for 1-2hrs and had no errors. (could have been too short of a test to verify)

I guess I just need help figuring out how to go about this, or if it is better off to stick to 32 gigs in my situation. I game but also utilize local LLMs and VMs, hence the ram upgrade.

Thank you in advance for the help!

[UPDATE]:

Just after writing this post, I received another kernel panic while just running two sticks of ram:

KERNEL PANIC!

stack-protector: Kernel stack is corrupted in: __schedule +0x15d9/0x1650

[UPDATE 2]

Almost 2 hours of using my computer with the ram configuration (per-channel serial number) for 4 sticks, My KDE Plasma instance froze and I had to hard reboot.

Hardware:

Motherboard: MSI PRO B650-S WIFI
CPU: AMD Ryzen 7 7700X
GPU: Radeon RX 7800XT
MEMORY: 4x16 TEAMGROUP EXPERT DDR5 6000 (1Rx8) CL30-36-36-76 1.35V

Last edited by qxbash (2026-05-11 19:26:15)

cryptearth · 2026-05-11 17:19:55

are the two kits EXACTLY the same? as in: do they share the same model EXACTLY (usually reflect in parts of the serial)? could be you have two unmatched kits - these usually only work with base jedec speed

qxbash · 2026-05-11 17:24:06

cryptearth wrote:

are the two kits EXACTLY the same? as in: do they share the same model EXACTLY (usually reflect in parts of the serial)? could be you have two unmatched kits - these usually only work with base jedec speed

Yes, they are both identical. I'm confused why this is also happening while running my regular 32 gigs as well. Anyways, it still crashes on base JEDEC speeds.

Last edited by qxbash (2026-05-11 17:26:10)

cryptearth · 2026-05-11 17:40:12

check for bios update - latest is 7E26v1N2

qxbash · 2026-05-11 17:53:49

cryptearth wrote:

check for bios update - latest is 7E26v1N2

I just updated bios and double checked the ram, you were right about the serial numbers being slightly off between the kits. I put the modules ending in 207 and 208 in slots 2 and 4, the 508 and 509 in 1 and 3.

Here is my motherboard manual for reference:

https://imgur.com/a/Ec8qxWf

cryptearth · 2026-05-11 20:19:56

as for the serial: it's not about what differs but what's the same
usually the serial somehow encode the modeltype (i remember back in ddr3 days a corsair kit hat the model as the first part of the serial, then i guess the batch and last the actual serial - and was quite long therefor) - but doing like you: one kit in 2 and 4, the other in 1 and 3, that's exactly how it should be done correctly
so - from that point - given these are matched kits and roughly within the same area of serial (which hints same model, maybe even same batch) they should work - at least at base jedec speed

but as you mentioned it's not even stable at jedec speeds ... give re-seating your cpu a try - am5 has changed to lga same as intel long time ago - maybe it's a bad contact of one of the memory pins

qxbash · 2026-05-12 01:08:56

cryptearth wrote:

as for the serial: it's not about what differs but what's the same
usually the serial somehow encode the modeltype (i remember back in ddr3 days a corsair kit hat the model as the first part of the serial, then i guess the batch and last the actual serial - and was quite long therefor) - but doing like you: one kit in 2 and 4, the other in 1 and 3, that's exactly how it should be done correctly
so - from that point - given these are matched kits and roughly within the same area of serial (which hints same model, maybe even same batch) they should work - at least at base jedec speed
but as you mentioned it's not even stable at jedec speeds ... give re-seating your cpu a try - am5 has changed to lga same as intel long time ago - maybe it's a bad contact of one of the memory pins

Thanks for insight, just re-seated the CPU, I noticed right away that booting was faster. I was also able to enable CPU Game-mode and EXPO Profile 2 (5600) with no issues, booting back from BIOS after those changes took half the time as well.

Last edited by qxbash (2026-05-12 01:09:19)

cryptearth · 2026-05-12 05:03:48

so at least 5600 stable then? how about 6000?

qxbash · 2026-05-12 05:11:05

cryptearth wrote:

so at least 5600 stable then? how about 6000?

Apparently not, my system froze and crashed again. I get a dbus error on boot now and my screen goes blank, regardless of what kernel I pick in the systemd boot screen.

It seems this is just waterfalling into more issues.

dimich · 2026-05-12 05:22:49

CPU or other component voltage is too low or unstable? Additional memory sticks may just increase disturbance in entire power bus.

qxbash · 2026-05-12 05:29:20

dimich wrote:

CPU or other component voltage is too low or unstable? Additional memory sticks may just increase disturbance in entire power bus.

I cannot even mount my root and boot parts in live iso. Cannot lookup blockdev.

This is super frustrating, I'm getting so many issues back to back, and I am not even sure a fresh arch install will help at this point.

Last edited by qxbash (2026-05-12 05:34:23)

seth · 2026-05-12 05:54:19

Sanity check:

I initially figured out it was the ram since this never happened when I was running two.
I ran memtest86+ for 1-2hrs and had no errors. (could have been too short of a test to verify)

The system is stable w/ only the two old or two new DIMMs?

Edit, F5

I cannot even mount my root and boot parts in live iso. Cannot lookup blockdev.

Why not?
The usual suspect is https://wiki.archlinux.org/title/Ryzen#Troubleshooting

while true; do
for ((i=0; i < $(nproc); ++i)); do
    taskset -c $i stress -c 1 -t 360
    sleep 15
done
done

emulates corecycler which is reported to be able to reliably trigger those problems on windows

Last edited by seth (2026-05-12 06:01:06)

qxbash · 2026-05-12 15:01:13

seth wrote:

Sanity check:
I initially figured out it was the ram since this never happened when I was running two.
I ran memtest86+ for 1-2hrs and had no errors. (could have been too short of a test to verify)
The system is stable w/ only the two old or two new DIMMs?
Edit, F5
I cannot even mount my root and boot parts in live iso. Cannot lookup blockdev.
Why not?
The usual suspect is https://wiki.archlinux.org/title/Ryzen#Troubleshooting
while true; do
for ((i=0; i < $(nproc); ++i)); do
    taskset -c $i stress -c 1 -t 360
    sleep 15
done
done
emulates corecycler which is reported to be able to reliably trigger those problems on windows

I will try adding the cpu kernel parameter for the softlock section of the troubleshooting, the cpu might be the culprit for some of the freezes.

The the stability was about the same for base speeds for running just the two old dimms and all four, system freezes (and/or pixely blue distortion on my second monitor) happen with the system being up for over an hour. Sometimes audio loops if music or a video is playing, and sometimes it simply freezes.

qxbash · Yesterday 19:46:05

I found something relevant indicating a kernel panic through journalctl:

May 14 12:14:07 archlinux kernel: kfd kfd: added device 1002:747e
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: SE 3, SH per SE 2, CU per SH 10, active_cu_number 60
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.2.0 uses VM inv eng 6 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.3.0 uses VM inv eng 7 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.0.1 uses VM inv eng 8 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.1.1 uses VM inv eng 9 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.2.1 uses VM inv eng 10 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring comp_1.3.1 uses VM inv eng 11 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring sdma0 uses VM inv eng 12 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring sdma1 uses VM inv eng 13 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring vcn_unified_0 uses VM inv eng 0 on hub 8
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring vcn_unified_1 uses VM inv eng 1 on hub 8
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring jpeg_dec uses VM inv eng 4 on hub 8
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
May 14 12:14:07 archlinux kernel: amdgpu: HMM registered 16368MB device memory
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: Using BACO for runtime pm
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: [drm] Registered 4 planes with drm panic
May 14 12:14:07 archlinux kernel: [drm] Initialized amdgpu 3.64.0 for 0000:03:00.0 on minor 1
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
May 14 12:14:07 archlinux kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 14 12:14:07 archlinux kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
May 14 12:14:07 archlinux kernel: Console: switching to colour frame buffer device 240x67
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: enabling device (0006 -> 0007)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: initializing kernel modesetting (IP DISCOVERY 0x1002:0x164E 0x1462:0x7E26 0xC3).
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: register mmio base: 0xDF500000
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: register mmio size: 524288
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 0 <common_v1_0_0> (nv_common)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 1 <gmc_v10_0_0> (gmc_v10_0)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 2 <ih_v5_0_0> (navi10_ih)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 3 <psp_v13_0_0> (psp)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 4 <smu_v13_0_0> (smu)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 5 <dce_v1_0_0> (dm)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 6 <gfx_v10_0_0> (gfx_v10_0)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 7 <sdma_v5_2_0> (sdma_v5_2)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 8 <vcn_v3_0_0> (vcn_v3_0)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: detected ip block number 9 <jpeg_v3_0_0> (jpeg_v3_0)
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: Fetched VBIOS from VFCT
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: [drm] ATOM BIOS: 102-RAPHAEL-008
May 14 12:14:07 archlinux kernel: amdgpu 0000:13:00.0: Trusted Memory Zone (TMZ) feature disabled as experimental (default)

None of the CPU freeze, PSU idle settings, or GPU kernel params have worked thus far.

My main monitor uses display port and my secondary has that HDMI address. I am back to troubleshooting the GPU (and iGPU) to see why HDMI-A-1 indicates a DRM error.

Last edited by qxbash (Yesterday 21:16:23)

seth · Yesterday 19:59:59

Please use [code][/code] tags.
Nothing there is directly indicating a problem to the degree of a kernel panic.

May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22

could however be symptom of a wider problem.
https://bbs.archlinux.org/viewtopic.php?id=309798

Do you not have any issues w/o the HDMI output attached?

But also check

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

qxbash · Yesterday 21:15:14

seth wrote:

Please use [code][/code] tags.
Nothing there is directly indicating a problem to the degree of a kernel panic.
May 14 12:14:07 archlinux kernel: amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
could however be symptom of a wider problem.
https://bbs.archlinux.org/viewtopic.php?id=309798
Do you not have any issues w/o the HDMI output attached?
But also check
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

Yes, with or without my dGPu, and without the second monitor, the screen freezes and no Kernel Panic blue screen is present.

May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: SMU is initialized successfully!
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] Display Core v3.2.369 initialized on DCN 3.1.5
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] DP-HDMI FRL PCON supported
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] DMUB hardware initialized: version=0x05002F00
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] HDMI-A-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* lttpr_caps phy_repeater_cnt is 0x0, forcing it to 0x80.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] DP-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] DP-2: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] DP-3: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: kiq ring mec 2 pipe 1 q 0
May 14 16:06:56 archlinux kernel: kfd kfd: Allocated 3969056 bytes on gart
May 14 16:06:56 archlinux kernel: kfd kfd: Total number of KFD nodes to be created: 1
May 14 16:06:56 archlinux kernel: amdgpu: Virtual CRAT table created for GPU
May 14 16:06:56 archlinux kernel: amdgpu: Topology: Add GPU node [0x1002:0x164e]
May 14 16:06:56 archlinux kernel: kfd kfd: added device 1002:164e
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: SE 1, SH per SE 1, CU per SH 2, active_cu_number 2
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring gfx_0.1.0 uses VM inv eng 1 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.0.0 uses VM inv eng 4 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.1.0 uses VM inv eng 5 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.2.0 uses VM inv eng 6 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.3.0 uses VM inv eng 7 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.0.1 uses VM inv eng 8 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.1.1 uses VM inv eng 9 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.2.1 uses VM inv eng 10 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring comp_1.3.1 uses VM inv eng 11 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring sdma0 uses VM inv eng 13 on hub 0
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring vcn_dec_0 uses VM inv eng 0 on hub 8
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: ring jpeg_dec uses VM inv eng 5 on hub 8
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: Runtime PM not available
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] Registered 4 planes with drm panic
May 14 16:06:56 archlinux kernel: [drm] Initialized amdgpu 3.64.0 for 0000:10:00.0 on minor 1
May 14 16:06:56 archlinux kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 14 16:06:56 archlinux kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:56 archlinux kernel: amdgpu 0000:10:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present.
May 14 16:06:57 archlinux kernel: Console: switching to colour frame buffer device 160x45
May 14 16:06:57 archlinux kernel: amdgpu 0000:10:00.0: [drm] fb0: amdgpudrmfb frame buffer device
May 14 16:06:57 archlinux systemd[1]: systemd-udevd.service: Deactivated successfully.
May 14 16:06:57 archlinux systemd[1]: Stopped Rule-based Manager for Device Events and Files.
May 14 16:06:57 archlinux systemd[1]: systemd-udevd.service: Consumed 1.700s CPU time over 1.889s wall clock time, 35.8M memory peak.

Journal logs dont show for when the computer crashes, at this point I am aimlessly trying to find a solution.

Last edited by qxbash (Yesterday 21:21:27)

cryptearth · Yesterday 21:28:24

just as with the cpu: have you tried to reseat the gpu?
it's been years but back in about 2011 i already tinkered a lot with hardware and just by a tip from friend we figured the pins inside a pci slots have suffered from corrosion and hence made bad contact with the pads on the inserted card - which lead to all kind of issues
these days slot contacts are usually more robust even in more harsh clinates - and anyone remember back in 90s when we use to blow into our cardridges? often it wasn't the blow but just the actual reinsertion what made better contact

seth · Yesterday 21:31:25

with or without my dGPu […] the screen freezes

The tail of the journal will be lost when rebooting w/ the power button, if you can use https://wiki.archlinux.org/title/Keyboa … el_(SysRq) + REISUB (bn. that you'll have to explicitly enable that first)
Which of the parameters suggested in https://wiki.archlinux.org/title/Ryzen#Troubleshooting do you currently apply? Do they show up in

cat /proc/cmdline

?
Can you control the CPU voltage or PBO offset in the UEFI?

Arch Linux

#1 2026-05-11 16:55:23

Kernel Panic and system freezes with 4x16 DDR5

#2 2026-05-11 17:19:55

Re: Kernel Panic and system freezes with 4x16 DDR5

#3 2026-05-11 17:24:06

Re: Kernel Panic and system freezes with 4x16 DDR5

#4 2026-05-11 17:40:12

Re: Kernel Panic and system freezes with 4x16 DDR5

#5 2026-05-11 17:53:49

Re: Kernel Panic and system freezes with 4x16 DDR5

#6 2026-05-11 20:19:56

Re: Kernel Panic and system freezes with 4x16 DDR5

#7 2026-05-12 01:08:56

Re: Kernel Panic and system freezes with 4x16 DDR5

#8 2026-05-12 05:03:48

Re: Kernel Panic and system freezes with 4x16 DDR5

#9 2026-05-12 05:11:05

Re: Kernel Panic and system freezes with 4x16 DDR5

#10 2026-05-12 05:22:49

Re: Kernel Panic and system freezes with 4x16 DDR5

#11 2026-05-12 05:29:20

Re: Kernel Panic and system freezes with 4x16 DDR5

#12 2026-05-12 05:54:19

Re: Kernel Panic and system freezes with 4x16 DDR5

#13 2026-05-12 15:01:13

Re: Kernel Panic and system freezes with 4x16 DDR5

#14 Yesterday 19:46:05

Re: Kernel Panic and system freezes with 4x16 DDR5

#15 Yesterday 19:59:59

Re: Kernel Panic and system freezes with 4x16 DDR5

#16 Yesterday 21:15:14

Re: Kernel Panic and system freezes with 4x16 DDR5

#17 Yesterday 21:28:24

Re: Kernel Panic and system freezes with 4x16 DDR5

#18 Yesterday 21:31:25

Re: Kernel Panic and system freezes with 4x16 DDR5

Board footer