Random system freezes/reboots

davidovitch · 2025-04-21 16:44:17

Gricenchos wrote:

I'll start with updating the BIOS. For some reason I can only find it in .exe format on Lenovo's support page? Strange.
Edit: the options mentioned aren't in UEFI at all, and updating BIOS might require making a windows partition, at least according to the Lenovo forums.
Edit #2: after removing all the kernel parameters, the situation has returned to what it was before: just black screen freeze.
Edit #3: parameter 'pci=nomsi' makes it so that loading into any of the kernels doesn't work at all. The laptop simply freezes.

I can see that there are is at least some part of the Lenovo Legion firmware that can be updated via fwupd. Could be useful for coming updates.

Is the UEFI/BIOS documented so poorly for Lenovo Legions? The only thing I could find is this: https://download.lenovo.com/pccbbs/pubs … tings.html. For my ASUS based motherboards I usually get at least a basic description of all UEFI/BIOS configuration options.

GMP · 2025-04-21 17:42:21

Gricenchos wrote:
Sadly, the issue has resurfaced. Not during a suspend at all.

Okay, this is something new.
The panic no longer requires suspend. So it's not a resume bug — it's a power state bug, likely triggered by idle, screen-off, or display power-saving logic.
You’re still seeing:

amdgpu: SMU driver if version not matched
[drm] Cannot find any crtc or sizes

...right before the crash. That makes DCN/SMU interaction the top suspect.

Strategy: prevent the system from entering display-related low-power states. Keep the GPU busy and awake.
---
1. Disable lid handling + idle actions (system-level)
Edit:

/etc/systemd/logind.conf

Uncomment or add these:

HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
IdleAction=ignore

Then either reboot or run:

systemctl restart systemd-logind.service

---
2. Disable display power saving (X11 only)
Run this in your session (or add to startup):

xset s off
xset -dpms
xset s noblank

Check current values with:

xset q

---
3. Wayland? Figure it out yourself.
If you're running Wayland, find its display idle settings and disable them manually.
---
Once this is in place, leave the system idle for 24–48h and see if the panic reproduces. If it survives, we just confirmed a power-state trigger.
Still test with multiple kernels, and keep posting traces when it breaks.

seth · 2025-04-21 18:27:10

апр 21 16:02:56 ZAX512L kernel: mce: [Hardware Error]: Machine check events logged
апр 21 16:02:56 ZAX512L kernel: [Hardware Error]: Corrected error, no action required.
апр 21 16:02:56 ZAX512L kernel: [Hardware Error]: CPU:10 (19:44:1) MC0_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0x9c20400002000175
апр 21 16:02:56 ZAX512L kernel: [Hardware Error]: Error Addr: 0x0000000247fa12ac
апр 21 16:02:56 ZAX512L kernel: [Hardware Error]: IPID: 0x001000b000000000, Syndrome: 0x0000006e1a1f0a05

https://wiki.archlinux.org/title/Ryzen#Random_reboots - esp. also see teh gentoo wiki link which has almost exactly your MCE…
According to google™ this is a Legion7 and those /do/ allow to control this (apparently in some AMD overclocking submenu)

Gricenchos · 2025-04-21 20:01:50

davidovitch wrote:

I can see that there are is at least some part of the Lenovo Legion firmware that can be updated via fwupd. Could be useful for coming updates.
Is the UEFI/BIOS documented so poorly for Lenovo Legions? The only thing I could find is this: https://download.lenovo.com/pccbbs/pubs … tings.html. For my ASUS based motherboards I usually get at least a basic description of all UEFI/BIOS configuration options.

I've circumvented using fwupd with a windows-to-go usb. Not sure about the documentation, I wasn't able to unearth much.

seth wrote:

According to google™ this is a Legion7 and those /do/ allow to control this (apparently in some AMD overclocking submenu)

From what I've gathered, it requires a windows utility, which might call for that windows-to-go approach again. Will look deeper into it.

GMP wrote:

So it's not a resume bug — it's a power state bug, likely triggered by idle, screen-off, or display power-saving logic.

The interesting thing is, it happened again after wards in the span of an hour, and both times I've had Firefox open and active. Not sure what to make of it.
Anyways, will try these recommendations and report.

Gricenchos · 2025-04-23 05:54:21

Okay, so after adding these:

HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
IdleAction=ignore

To logind.conf I had a stable uptime of 24h. This includes closing the laptop's lid and letting it sleep for the night. However, on waking it in the morning, the wifi broke, and attempting to restart led to the system freezing up. Not the machine as a whole though - it wasn't a kernel panic, and reboot with alt+sysrq+b worked. Not sure what to make of it.

seth · 2025-04-23 06:42:04

attempting to restart led to the system freezing up. Not the machine as a whole though - it wasn't a kernel panic, and reboot with alt+sysrq+b worked

did you alt+sysrq+reisub (notably the "s" and the "u")?
Please post your complete system journal for the boot, probably

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous one.

Gricenchos · 2025-04-23 08:56:43

seth wrote:

did you alt+sysrq+reisub (notably the "s" and the "u")?
Please post your complete system journal for the boot, probably
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
for the previous one.

Sadly, just alt+sysrq+b. Here are the logs anyways:

http://0x0.st/8VSK.txt

Gricenchos · 2025-04-23 09:13:43

And just got another kernel panic after all. Not on suspend or anything like that, just had my browser opened on this very same page.

Panic report:

https://tinyurl.com/423awer3

seth · 2025-04-23 14:48:24

No sysrq is logged in http://0x0.st/8VSK.txt - did you attempt to restart the wifi or the system?

Ooops, then panic:

[14816.342766] BUG: unable to handle page fault for address: 0000000080000007
[14816.342777] #PF: supervisor read access in kernel mode
[14816.342784] #PF: error_code(0x0000) - not-present page
[14816.342790] PGD 0 P4D 0 
[14816.342799] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
---------------------------------------------------
[14816.342807] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.14.2-zen1-1-zen #1 218dc6f0ba61db4f373647be0c0a9ff09a60d2a9
[14816.342816] Hardware name: LENOVO 82UG/LNVNB161216, BIOS KFCN42WW 12/03/2024
[14816.342821] RIP: 0010:tick_nohz_idle_exit+0xb1/0x170
-------------------------------------------------------
[14816.342831] Code: eb ff ff 4d 89 ac 24 c0 00 00 00 66 90 48 8b 3d 65 c4 15 02 49 2b 7c 24 68 48 ba fd ff ff ff ff ff ff 7f 48 8d 47 ff 48 39 c2 <72> a5 e8 28 f8 f5 ff eb 9e 65 80 3d 9e 4c f8 76 00 75 94 eb ce 80
[14816.342837] RSP: 0018:ffffffff8b203e50 EFLAGS: 00010006
[14816.342845] RAX: 0000000000000007 RBX: 0000000000000002 RCX: 0000000000000020
[14816.342850] RDX: 7ffffffffffffffd RSI: 0000000000000083 RDI: 0000000000000008
[14816.342855] RBP: ffff99c386200000 R08: 0000000000000000 R09: 7fffffffffffffff
[14816.342860] R10: 00000d79a4f93701 R11: 00000000006aeaad R12: ffff99c386226040
[14816.342865] R13: 00000d79a4f9526d R14: 000000000078358b R15: 00000000a452d000
[14816.342870] FS:  0000000000000000(0000) GS:ffff99c386200000(0000) knlGS:0000000000000000
[14816.342875] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[14816.342880] CR2: 0000000080000007 CR3: 000000010591c000 CR4: 0000000000f50ef0
[14816.342886] PKRU: 55555554
[14816.342890] Call Trace:
[14816.342895]  <TASK>
[14816.342904]  do_idle+0x139/0x210
[14816.342915]  cpu_startup_entry+0x29/0x30
[14816.342922]  rest_init+0xcc/0xd0
[14816.342932]  start_kernel+0x989/0x990
[14816.342944]  x86_64_start_reservations+0x24/0x30
[14816.342954]  x86_64_start_kernel+0x95/0xa0
[14816.342962]  common_startup_64+0x13e/0x141
[14816.342976]  </TASK>
[14816.342980] Modules linked in: udp_diag tcp_diag inet_diag uinput ccm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_ctl_led snd_acp6x_pdm_dma snd_soc_acp6x_mach snd_soc_dmic snd_sof_amd_acp70 snd_sof_amd_acp63 snd_sof_amd_vangogh vfat snd_sof_amd_rembrandt fat amd_atl snd_sof_amd_renoir intel_rapl_msr intel_rapl_common snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils amdgpu snd_pci_ps snd_soc_acpi_amd_match mt7921e snd_amd_sdw_acpi mt7921_common soundwire_amd snd_hda_codec_realtek soundwire_generic_allocation mt792x_lib soundwire_bus kvm_amd mt76_connac_lib snd_hda_codec_generic snd_soc_sdca mt76 snd_hda_scodec_cs35l41_spi snd_hda_scodec_component snd_soc_core kvm snd_hda_codec_hdmi amdxcp mac80211 gpu_sched snd_compress drm_panel_backlight_quirks ac97_bus drm_buddy snd_hda_intel snd_pcm_dmaengine polyval_clmulni drm_exec drm_suballoc_helper polyval_generic snd_intel_dspcfg snd_rpl_pci_acp6x uvcvideo drm_ttm_helper think_lmi
[14816.343149]  ghash_clmulni_intel snd_intel_sdw_acpi ttm videobuf2_vmalloc libarc4 snd_acp_pci sha512_ssse3 snd_hda_codec uvc snd_acp_legacy_common btusb sha256_ssse3 i2c_algo_bit videobuf2_memops spd5118 hid_multitouch firmware_attributes_class wmi_bmof videobuf2_v4l2 snd_hda_core snd_pci_acp6x ideapad_laptop sha1_ssse3 snd_hda_scodec_cs35l41_i2c drm_display_helper btrtl videobuf2_common snd_hwdep sp5100_tco snd_pci_acp5x cfg80211 aesni_intel platform_profile snd_hda_scodec_cs35l41 btintel cec snd_pcm snd_rn_pci_acp3x sparse_keymap snd_hda_cs_dsp_ctls crypto_simd ucsi_acpi btbcm snd_acp_config videodev snd_soc_cs_amp_lib i2c_piix4 btmtk video typec_ucsi cryptd snd_timer snd_soc_acpi snd_soc_cs35l41_lib bluetooth rapl typec pcspkr mc cs_dsp mousedev k10temp i2c_smbus ccp snd snd_pci_acp3x rfkill joydev roles soundcore wmi i2c_hid_acpi i2c_hid amd_pmc serial_multi_instantiate acpi_tad psmouse mac_hid pkcs8_key_parser i2c_dev crypto_user dm_mod loop nfnetlink zram 842_decompress 842_compress lz4hc_compress lz4_compress
[14816.343352]  ip_tables x_tables hid_logitech_hidpp hid_logitech_dj hid_generic usbhid rtsx_pci_sdmmc mmc_core serio_raw atkbd libps2 vivaldi_fmap nvme nvme_core i8042 rtsx_pci nvme_auth serio
[14816.343400] CR2: 0000000080000007
[14816.343406] ---[ end trace 0000000000000000 ]---
[14816.343412] RIP: 0010:tick_nohz_idle_exit+0xb1/0x170
[14816.343419] Code: eb ff ff 4d 89 ac 24 c0 00 00 00 66 90 48 8b 3d 65 c4 15 02 49 2b 7c 24 68 48 ba fd ff ff ff ff ff ff 7f 48 8d 47 ff 48 39 c2 <72> a5 e8 28 f8 f5 ff eb 9e 65 80 3d 9e 4c f8 76 00 75 94 eb ce 80
[14816.343424] RSP: 0018:ffffffff8b203e50 EFLAGS: 00010006
[14816.343431] RAX: 0000000000000007 RBX: 0000000000000002 RCX: 0000000000000020
[14816.343436] RDX: 7ffffffffffffffd RSI: 0000000000000083 RDI: 0000000000000008
[14816.343440] RBP: ffff99c386200000 R08: 0000000000000000 R09: 7fffffffffffffff
[14816.343443] R10: 00000d79a4f93701 R11: 00000000006aeaad R12: ffff99c386226040
[14816.343446] R13: 00000d79a4f9526d R14: 000000000078358b R15: 00000000a452d000
[14816.343450] FS:  0000000000000000(0000) GS:ffff99c386200000(0000) knlGS:0000000000000000
[14816.343453] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[14816.343456] CR2: 0000000080000007 CR3: 000000010591c000 CR4: 0000000000f50ef0
[14816.343459] PKRU: 55555554
[14816.343463] Kernel panic - not syncing: Attempted to kill the idle task!
[14816.343656] Kernel Offset: 0x7c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

https://bbs.archlinux.org/viewtopic.php … 0#p2238100 ?

Gricenchos · 2025-04-23 16:42:02

seth wrote:

https://bbs.archlinux.org/viewtopic.php … 0#p2238100 ?

I haven't delved into this, as basic BIOS settings for Lenovo don't seem to allow this. I'll look into disabling global c-states and report on the results.

Should I remove parameters 'processor.max_cstate=1 amd_iommu=off'?

seth · 2025-04-24 06:05:40

If you can disable the c-states in the BIOS, processor.max_cstate=1 becomes moot, amd_iommu=off is a different thing, I'd keep it there for the moment.
However feeding more voltage to the CPU by adjusting the curve optimizer/PBO (can you maybe completely disable the latter) is likely the only real fix to this.

Gricenchos · 2025-04-24 10:24:08

seth wrote:

However feeding more voltage to the CPU by adjusting the curve optimizer/PBO (can you maybe completely disable the latter) is likely the only real fix to this.

I'm looking into it. Never done anything like that before.

It seems that it can't be done using standard tools of my laptop model, but on Lenovo forums I've been recommended this utility: https://amdaputuningutility.com/#about I'll look into it and try it.

Does anybody have experience with it? I admit, I'm quite afraid of bricking my laptop by messing with these parameters.

Last edited by Gricenchos (2025-04-24 11:46:22)

seth · 2025-04-24 13:06:32

The tool? Specifically w/ your HW?
You're better off asking this on the lenovo forum.

Lenovos sometimes have secret shortcuts for advanced UEFI settings - Fn+R,Fn+N,Fn+R,Fn+N,Fn+R,Fn+N seems to be a thing, but "i heard that on the internet"

davidovitch · 2025-04-24 20:03:47

Gricenchos wrote:

seth wrote:
However feeding more voltage to the CPU by adjusting the curve optimizer/PBO (can you maybe completely disable the latter) is likely the only real fix to this.
I'm looking into it. Never done anything like that before.
It seems that it can't be done using standard tools of my laptop model, but on Lenovo forums I've been recommended this utility: https://amdaputuningutility.com/#about I'll look into it and try it.
Does anybody have experience with it? I admit, I'm quite afraid of bricking my laptop by messing with these parameters.

Personally, I wouldn't consider overclocking since I think the origin of your issue is well documented:
https://bugzilla.kernel.org/show_bug.cgi?id=196683
https://bugzilla.kernel.org/show_bug.cgi?id=206487
https://www.reddit.com/r/Amd/comments/c … ll_of_zen/
https://community.amd.com/t5/pc-process … d-p/156304

...and the only solution is to get into the BIOS/UEFI and disable C-states and set "common current idle".
Here's a thread with Youtube link that show what the advanced BIOS settings are on an Intel (different from AMD) Legion system: https://www.reddit.com/r/GamingLaptops/ … _bios_for/

seth · 2025-04-24 20:14:20

Ftr, adjusting the PBO / curve optimizer is NOT overclocking - if anything ratehr the contrary (the higher voltages will lead to higher temperatures limiting the boost individual cores can get)

High c-state related (notably C6) issues are well documented for ryzen CPUs as well (incl in the previously linked arch wiki), but I've not seen claims that the kernel side limitations would not work, but some BIOS setting does?

https://www.reddit.com/r/GamingLaptops/ … _bios_for/ btw. just boils down to Fn+R,Fn+N (though not thrice?)

GMP · Yesterday 09:54:18

Your crash:

tick_nohz_idle_exit
#PF: supervisor read access in kernel mode
CR2: 0x80000007

This means the kernel tried to access a non-present page during idle wakeup — likely memory corruption or instability.

1. Run memtest86+ to rule out RAM issues
Unreliable RAM will cause this exact failure mode.
Use memtest86+ – Arch Wiki as a reference.

Quick start:

Install:
```
sudo pacman -S memtest86+
```
Reboot → GRUB → select memtest86+ entry
Let it run overnight (2 full passes minimum)

---

2. BIOS Tuning (as @seth already suggested):
This class of Ryzen issue is widespread and documented:
Kernel Bug 206487 – Ryzen C6 panic

You want:

Global C-State Control → Disabled
Power Supply Idle Control → Typical Current Idle
(Optional) Curve Optimizer / PBO offset → for extra margin

Lenovo hides this by default. Some users report unlocking advanced BIOS with:

Fn+R, Fn+N (repeat on splash)

This isn't overclocking — raising voltage here helps stability, not performance.

---

3. AMD APU Tuning Utility
No one here has tested that tool on your hardware. If you go that way, ask on Lenovo forums. Risk sits with them, not with us.

Gricenchos · Yesterday 15:20:03

seth wrote:

https://www.reddit.com/r/GamingLaptops/ … _bios_for/ btw. just boils down to Fn+R,Fn+N (though not thrice?)

This didn't seem to work for me.

GMP wrote:

Your crash:
tick_nohz_idle_exit
#PF: supervisor read access in kernel mode
CR2: 0x80000007
This means the kernel tried to access a non-present page during idle wakeup — likely memory corruption or instability.
1. Run memtest86+ to rule out RAM issues
Unreliable RAM will cause this exact failure mode.
Use memtest86+ – Arch Wiki as a reference.
Quick start:
Install:
sudo pacman -S memtest86+
Reboot → GRUB → select memtest86+ entry
Let it run overnight (2 full passes minimum)
---
2. BIOS Tuning (as @seth already suggested):
This class of Ryzen issue is widespread and documented:
Kernel Bug 206487 – Ryzen C6 panic
You want:
Global C-State Control → Disabled
Power Supply Idle Control → Typical Current Idle
(Optional) Curve Optimizer / PBO offset → for extra margin
Lenovo hides this by default. Some users report unlocking advanced BIOS with:
Fn+R, Fn+N (repeat on splash)
This isn't overclocking — raising voltage here helps stability, not performance.
---
3. AMD APU Tuning Utility
No one here has tested that tool on your hardware. If you go that way, ask on Lenovo forums. Risk sits with them, not with us.

Thank you for the response. I'll run memtest tonight, will see the results.

I wasn't able to access advanced BIOS settings, sadly. I'll try asking on Lenovo forums - that's definitely an option I prefer over some third party software.

Last edited by Gricenchos (Yesterday 15:57:55)

GMP · Yesterday 15:59:27

Let's be methodical here — not guessing blindly.

First: Confirm your boot mode.
Run:

ls /sys/firmware/efi

- If the directory exists, you're booted in UEFI mode.
- If it doesn't, you're in legacy BIOS mode.

This matters because classic memtest86+ needs BIOS mode.
If you're pure UEFI, it won't show up in GRUB — not a bug, just a design limit.

---

Meanwhile:

If you confirm UEFI mode, prepare a fallback:

Download standalone memtest86+ ISO: Official memtest86+ ISO
Flash it to a USB stick.
Boot from USB → memtest runs standalone outside the OS.

This way you can continue diagnosing without delay, regardless of boot mode.

No reboot/reinstall/retry guessing — clear checks, clean next steps.

Gricenchos · Today 04:34:04

GMP wrote:

Let's be methodical here — not guessing blindly.
First: Confirm your boot mode.
Run:
ls /sys/firmware/efi
- If the directory exists, you're booted in UEFI mode.
- If it doesn't, you're in legacy BIOS mode.
This matters because classic memtest86+ needs BIOS mode.
If you're pure UEFI, it won't show up in GRUB — not a bug, just a design limit.
---
Meanwhile:
If you confirm UEFI mode, prepare a fallback:
Download standalone memtest86+ ISO: Official memtest86+ ISO
Flash it to a USB stick.
Boot from USB → memtest runs standalone outside the OS.
This way you can continue diagnosing without delay, regardless of boot mode.
No reboot/reinstall/retry guessing — clear checks, clean next steps.

I'm booted in UEFI mode. memtest86+-efi from arch repositories ran fine. I've ran it overnight and it didn't produce any errors. However, it came to me that I have mismatched memory modules: one 8gb Samsung and a 16gb Kingston. Might this be the issue? Because it does seem like it's the memory issue: even without kernel panics, some applications sometimes crash randomly or freeze. I still have the original second 8gb module, so maybe I'll put it back in and see if it changes anything.

Last edited by Gricenchos (Today 04:38:07)

seth · Today 06:32:13

From what I can see online, the device has one DIMM soldered, one slot - dual channel is only supported <= 16GB total, so yes, try the original module - esp. if you cannot adjust voltage, timings or anything else in the BIOS/UEFI.

GMP · Today 11:19:14

Gricenchos wrote:
However, it came to me that I have mismatched memory modules: one 8gb Samsung and a 16gb Kingston. Might this be the issue?

Good catch — the memory mismatch could explain random freezes and application crashes, even if memtest86+ showed no errors.

About the RAM configuration:

Your Legion 7 model (16ARHA7) has:

8GB soldered memory (onboard)
One DDR5 SO-DIMM slot

This model is dual-channel capable, but optimal dual-channel operation requires matching the soldered RAM size with the SO-DIMM.

If you mix 8GB soldered with a 16GB SO-DIMM, the system operates in "asymmetric dual-channel" or "flex mode":
- First 8GB from each module works in dual-channel.
- The extra 8GB from the 16GB module runs single-channel.

This mismatch can cause slight timing instability, especially under multitasking, sleep/wake transitions, or driver load.

---

About memtest86+ passing:

Passing memtest86+ means there are no raw bit errors.
But it doesn't simulate:

Sleep → wake transitions
Multicore simultaneous memory access
Real-world driver timing and loads

Flex mode mismatches can still cause runtime freezes, driver faults, or instability without producing memory corruption.

---

Recommended:

Revert to the original matching 8GB module.
Keep BIOS tuning (C-state disabling) on the roadmap for final CPU-side stability.

Clean separation of concerns leads to clean, final fixes.

Gricenchos · Today 12:52:40

seth wrote:

From what I can see online, the device has one DIMM soldered, one slot - dual channel is only supported <= 16GB total, so yes, try the original module - esp. if you cannot adjust voltage, timings or anything else in the BIOS/UEFI.

Well, sadly, that's not it. I've put the old memory module in, and still got another kernel panic after about 5h uptime.

Report:

https://tinyurl.com/b99psmwx

Edit: admittedly, I had processor.max_cstate=1 disabled at the moment. I'll keep the original memory module for now and restore the parameter.

Last edited by Gricenchos (Today 12:59:45)

Arch Linux

#26 2025-04-21 16:44:17

Re: Random system freezes/reboots

#27 2025-04-21 17:42:21

Re: Random system freezes/reboots

#28 2025-04-21 18:27:10

Re: Random system freezes/reboots

#29 2025-04-21 20:01:50

Re: Random system freezes/reboots

#30 2025-04-23 05:54:21

Re: Random system freezes/reboots

#31 2025-04-23 06:42:04

Re: Random system freezes/reboots

#32 2025-04-23 08:56:43

Re: Random system freezes/reboots

#33 2025-04-23 09:13:43

Re: Random system freezes/reboots

#34 2025-04-23 14:48:24

Re: Random system freezes/reboots

#35 2025-04-23 16:42:02

Re: Random system freezes/reboots

#36 2025-04-24 06:05:40

Re: Random system freezes/reboots

#37 2025-04-24 10:24:08

Re: Random system freezes/reboots

#38 2025-04-24 13:06:32

Re: Random system freezes/reboots

#39 2025-04-24 20:03:47

Re: Random system freezes/reboots

#40 2025-04-24 20:14:20

Re: Random system freezes/reboots

#41 Yesterday 09:54:18

Re: Random system freezes/reboots

#42 Yesterday 15:20:03

Re: Random system freezes/reboots

#43 Yesterday 15:59:27

Re: Random system freezes/reboots

#44 Today 04:34:04

Re: Random system freezes/reboots

#45 Today 06:32:13

Re: Random system freezes/reboots

#46 Today 11:19:14

Re: Random system freezes/reboots

#47 Today 12:52:40

Re: Random system freezes/reboots

Board footer