PVE host freezes every 2-3 weeks

C

co-creater

Member
Jun 10, 2024
12
1
6
Hello,

homelabber here, as described in the title, my system shows every 2-3 weeks (non-reproduceable) the following symptoms:
  • PVE unresponsive (ssh, web interface)
  • All LXC's services are hanging
  • HDMI connected monitor shows login screen but cursos is not blinking anymore
  • syslog is still producing output
  • Hard-reset is the only way to get the system back
Some log entries 20 minutes before the reboot and when the system was not responding anymore:
Code: 
Jul 12 16:48:45 pve kernel: overlayfs: fs on '/var/lib/docker/overlay2/l/6BZ6C3BZFOPZULMJMZEBOHIR63' does not support file handles, falling back to xino=off.
Jul 12 16:48:46 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered blocking state
Jul 12 16:48:46 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered disabled state
Jul 12 16:48:46 pve kernel: veth3baf17b: entered allmulticast mode
Jul 12 16:48:46 pve kernel: veth3baf17b: entered promiscuous mode
Jul 12 16:48:46 pve kernel: eth0: renamed from veth01b4fe4
Jul 12 16:48:46 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered blocking state
Jul 12 16:48:46 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered forwarding state
Jul 12 16:48:47 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered disabled state
Jul 12 16:48:47 pve kernel: veth01b4fe4: renamed from eth0
Jul 12 16:48:47 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered disabled state
Jul 12 16:48:47 pve kernel: veth3baf17b (unregistering): left allmulticast mode
Jul 12 16:48:47 pve kernel: veth3baf17b (unregistering): left promiscuous mode
Jul 12 16:48:47 pve kernel: br-6afff224798b: port 2(veth3baf17b) entered disabled state
Jul 12 16:49:47 pve kernel: overlayfs: fs on '/var/lib/docker/overlay2/l/6BZ6C3BZFOPZULMJMZEBOHIR63' does not support file handles, falling back to xino=off.
Jul 12 16:49:47 pve kernel: br-6afff224798b: port 2(vethe875113) entered blocking state
Jul 12 16:49:47 pve kernel: br-6afff224798b: port 2(vethe875113) entered disabled state
Jul 12 16:49:47 pve kernel: vethe875113: entered allmulticast mode
Jul 12 16:49:47 pve kernel: vethe875113: entered promiscuous mode
Jul 12 16:49:47 pve kernel: eth0: renamed from veth19b2068
Jul 12 16:49:47 pve kernel: br-6afff224798b: port 2(vethe875113) entered blocking state
Jul 12 16:49:47 pve kernel: br-6afff224798b: port 2(vethe875113) entered forwarding state
Jul 12 16:49:48 pve kernel: br-6afff224798b: port 2(vethe875113) entered disabled state
Jul 12 16:49:48 pve kernel: veth19b2068: renamed from eth0
Jul 12 16:49:48 pve kernel: br-6afff224798b: port 2(vethe875113) entered disabled state
Jul 12 16:49:48 pve kernel: vethe875113 (unregistering): left allmulticast mode
Jul 12 16:49:48 pve kernel: vethe875113 (unregistering): left promiscuous mode
Jul 12 16:49:48 pve kernel: br-6afff224798b: port 2(vethe875113) entered disabled state
Jul 12 16:50:48 pve kernel: overlayfs: fs on '/var/lib/docker/overlay2/l/6BZ6C3BZFOPZULMJMZEBOHIR63' does not support file handles, falling back to xino=off.
Jul 12 16:50:48 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered blocking state
Jul 12 16:50:48 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered disabled state
Jul 12 16:50:48 pve kernel: vethd7c9d4a: entered allmulticast mode
Jul 12 16:50:48 pve kernel: vethd7c9d4a: entered promiscuous mode
Jul 12 16:50:48 pve kernel: eth0: renamed from veth1aeb980
Jul 12 16:50:48 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered blocking state
Jul 12 16:50:48 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered forwarding state
Jul 12 16:50:49 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered disabled state
Jul 12 16:50:49 pve kernel: veth1aeb980: renamed from eth0
Jul 12 16:50:49 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered disabled state
Jul 12 16:50:49 pve kernel: vethd7c9d4a (unregistering): left allmulticast mode
Jul 12 16:50:49 pve kernel: vethd7c9d4a (unregistering): left promiscuous mode
Jul 12 16:50:49 pve kernel: br-6afff224798b: port 2(vethd7c9d4a) entered disabled state
-- Boot 0e40f1576dff4087a3723c01cf5febeb --

Some log messages after the reboot:
Code: 
-- Boot 0e40f1576dff4087a3723c01cf5febeb --
Jul 12 16:52:32 pve kernel: Linux version 7.0.12-1-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 7.0.12-1 (2026-06-09T21:07Z) ()
Jul 12 16:52:32 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.12-1-pve root=/dev/mapper/pve-root ro quiet
Jul 12 16:52:32 pve kernel: KERNEL supported cpus:
Jul 12 16:52:32 pve kernel:   Intel GenuineIntel
Jul 12 16:52:32 pve kernel:   AMD AuthenticAMD
Jul 12 16:52:32 pve kernel:   Hygon HygonGenuine
Jul 12 16:52:32 pve kernel:   Centaur CentaurHauls
Jul 12 16:52:32 pve kernel:   zhaoxin   Shanghai 
Jul 12 16:52:32 pve kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
Jul 12 16:52:32 pve kernel: BIOS-provided physical RAM map:
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff]  System RAM
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009efff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff]  System RAM
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000072332fff]  System RAM
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000072333000-0x0000000075432fff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000075433000-0x0000000075527fff]  ACPI data
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000075528000-0x00000000755e7fff]  ACPI NVS
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000755e8000-0x0000000075ffefff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000075fff000-0x0000000075ffffff]  System RAM
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000076000000-0x0000000079ffffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x000000007a000000-0x000000007a9fffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x000000007aa00000-0x000000007abfffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x000000007ac00000-0x000000007affffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x000000007b000000-0x00000000803fffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x0000000080400000-0x00000000bfffffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000c0000000-0x00000000cfffffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000d0000000-0x00000000fdffffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000fe011000-0x00000000febfffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000fec01000-0x00000000fecfffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000fed01000-0x00000000fed1ffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000fed20000-0x00000000fed7ffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000fed80000-0x00000000fedfffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [gap 0x00000000fee01000-0x00000000feffffff]
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff]  device reserved
Jul 12 16:52:32 pve kernel: BIOS-e820: [mem 0x0000000100000000-0x000000087fbfffff]  System RAM
Jul 12 16:52:32 pve kernel: NX (Execute Disable) protection: active
Jul 12 16:52:32 pve kernel: APIC: Static calls initialized
Jul 12 16:52:32 pve kernel: efi: EFI v2.8 by American Megatrends
Jul 12 16:52:32 pve kernel: efi: ACPI=0x755a4000 ACPI 2.0=0x755a4014 TPMFinalLog=0x75573000 SMBIOS=0x75c62000 SMBIOS 3.0=0x75c61000 ESRT=0x7062f918 MOKvar=0x75cb6000 INITRD=0x6e47ce18 RNG=0x75474018 TPMEventLog=0x75469018
Jul 12 16:52:32 pve kernel: random: crng init done
Jul 12 16:52:32 pve kernel: efi: Remove mem75: MMIO range=[0xc0000000-0xcfffffff] (256MB) from e820 map
Jul 12 16:52:32 pve kernel: e820: remove [mem 0xc0000000-0xcfffffff] device reserved
Jul 12 16:52:32 pve kernel: efi: Not removing mem76: MMIO range=[0xfe000000-0xfe010fff] (68KB) from e820 map
Jul 12 16:52:32 pve kernel: efi: Not removing mem77: MMIO range=[0xfec00000-0xfec00fff] (4KB) from e820 map
Jul 12 16:52:32 pve kernel: efi: Not removing mem78: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map
Jul 12 16:52:32 pve kernel: efi: Not removing mem80: MMIO range=[0xfee00000-0xfee00fff] (4KB) from e820 map
Jul 12 16:52:32 pve kernel: efi: Remove mem81: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map
Jul 12 16:52:32 pve kernel: e820: remove [mem 0xff000000-0xffffffff] device reserved
Jul 12 16:52:32 pve kernel: SMBIOS 3.5.0 present.
Jul 12 16:52:32 pve kernel: DMI: BIOSTAR Group H610MHP/H610MHP, BIOS  09/12/2022
Jul 12 16:52:32 pve kernel: DMI: Memory slots populated: 1/2
Jul 12 16:52:32 pve kernel: secureboot: Secure boot disabled
Jul 12 16:52:32 pve kernel: tsc: Detected 3400.000 MHz processor
Jul 12 16:52:32 pve kernel: tsc: Detected 3417.600 MHz TSC
Jul 12 16:52:32 pve kernel: e820: update [mem 0x00000000-0x00000fff] System RAM ==> device reserved
Jul 12 16:52:32 pve kernel: e820: remove [mem 0x000a0000-0x000fffff] System RAM
Jul 12 16:52:32 pve kernel: last_pfn = 0x87fc00 max_arch_pfn = 0x400000000
Jul 12 16:52:32 pve kernel: MTRR map: 5 entries (3 fixed + 2 variable; max 23), built from 10 variable MTRRs
Jul 12 16:52:32 pve kernel: x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT 
Jul 12 16:52:32 pve kernel: last_pfn = 0x76000 max_arch_pfn = 0x400000000
Jul 12 16:52:32 pve kernel: esrt: Reserving ESRT space from 0x000000007062f918 to 0x000000007062f9a0.
Jul 12 16:52:32 pve kernel: e820: update [mem 0x7062f000-0x7062ffff] System RAM ==> device reserved

Some system infos:
  • 1 PVE host
  • 10-15 permanently running LXC (with Docker installed on some LXC if this is important...)
  • 0 running VMs when the freeze happens
  • 4 HDDs in RAID10 zfs configuration
  • 1 NVME used as boot partition (23 % wearout after 3 years)
pveversion -v:
Code: 
proxmox-ve: 9.2.0 (running kernel: 7.0.12-1-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.12-1
proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
proxmox-kernel-7.0.0-3-pve-signed: 7.0.0-3
proxmox-kernel-6.17: 6.17.13-13
proxmox-kernel-6.17.13-13-pve-signed: 6.17.13-13
proxmox-kernel-6.17.13-11-pve-signed: 6.17.13-11
proxmox-kernel-6.17.13-6-pve-signed: 6.17.13-6
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.17.13-1-pve-signed: 6.17.13-1
proxmox-kernel-6.17.9-1-pve-signed: 6.17.9-1
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.17.4-1-pve-signed: 6.17.4-1
proxmox-kernel-6.17.2-2-pve-signed: 6.17.2-2
proxmox-kernel-6.8: 6.8.12-17
proxmox-kernel-6.8.12-17-pve-signed: 6.8.12-17
proxmox-kernel-6.8.12-14-pve-signed: 6.8.12-14
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
ceph-fuse: 19.2.3-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.5
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.8.0
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.17
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
uname -a
Code: 
Linux pve 7.0.12-1-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.12-1 (2026-06-09T21:07Z) x86_64 GNU/Linux

lscpu excerpt
Code: 
Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             39 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      8
  On-line CPU(s) list:       0-7
Vendor ID:                   GenuineIntel
  Model name:                13th Gen Intel(R) Core(TM) i3-13100
Mainboard is a consumer BIOSTAR H610MHP.

According to a similar thread https://forum.proxmox.com/threads/proxmox-keeps-freezing-every-2-3-days.179267/ I installed also intel-microcode. But the freeze happened also with it. I'm running out of ideas. I checked the log entries with Claude and it "thinks" that there are no critical log entries before the freeze.

What else can I check?

Thank you in advance!
 
There's a signature in your logs worth pointing out. In the minutes before the freeze:

16:48:46 veth3baf17b → forwarding → disabled
16:49:47 vethe875113 → forwarding → disabled
16:50:48 vethd7c9d4a → forwarding → disabled

A Docker container is restarting every ~60s on a Docker bridge (`br-6afff...`). Combined with the repeating

overlayfs: fs on '...' does not support file handles, falling back to xino=off

= Docker overlay2 running degraded on ZFS + a container restart loop.

Your key symptom — "syslog still writing while everything else is frozen" — points to memory pressure, not a kernel panic. Kernel log writers stay alive because they're already in-kernel; new syscalls (SSH, HTTP, TTY) can't get served because reclaim can't keep up.
Cumulative over weeks, no single "critical" log event.

My working hypothesis: Docker-in-LXC on ZFS + restart loop building memory pressure until reclaim gives up.

Could you post:
- `docker ps -a` restart counts
- `arc_summary | head -30`
- `cat /proc/pressure/memory`
- Total RAM (`free -h`)

That'll tell us if we're on the memory pressure track or need to look elsewhere.
 
The H610MHP seems to use a NIC that uses the e1000e driver. Have you looked into fixes for it? You also need to update your outdated UEFI. Yours is from 2022.
 
  • Like
Reactions: Johannes S
Mr.Doubt said:
You have docker container running on pve?
Click to expand...
Of course not! But inside some LXCs.
g.fiore said:
There's a signature in your logs worth pointing out. In the minutes before the freeze:

16:48:46 veth3baf17b → forwarding → disabled
16:49:47 vethe875113 → forwarding → disabled
16:50:48 vethd7c9d4a → forwarding → disabled

A Docker container is restarting every ~60s on a Docker bridge (`br-6afff...`). Combined with the repeating
Click to expand...
I found the responsible Docker container and stopped it. It was a watchtower container.
g.fiore said:
overlayfs: fs on '...' does not support file handles, falling back to xino=off

= Docker overlay2 running degraded on ZFS + a container restart loop.

Your key symptom — "syslog still writing while everything else is frozen" — points to memory pressure, not a kernel panic. Kernel log writers stay alive because they're already in-kernel; new syscalls (SSH, HTTP, TTY) can't get served because reclaim can't keep up.
Cumulative over weeks, no single "critical" log event.

My working hypothesis: Docker-in-LXC on ZFS + restart loop building memory pressure until reclaim gives up.
Click to expand...
Just some additional info: All LXCs are stored on the NVME drive on loval-lvm. The ZFS RAID10 is only for mass data storage and is mounted inside the LXC which require it using mount-points.

Could you post:
g.fiore said:
- `docker ps -a` restart counts
- `arc_summary | head -30`
- `cat /proc/pressure/memory`
- Total RAM (`free -h`)
Click to expand...
docker ps I would leave it for now as I identified the container that produced all these log entries about blocking state etc.
For the rest:
Code: 
root@pve:~# arc_summary | head -30

------------------------------------------------------------------------
ZFS Subsystem Report                            Mon Jul 13 10:27:17 2026
Linux 7.0.12-1-pve                                            2.4.2-pve1
Machine: pve (x86_64)                                         2.4.2-pve1

ARC status:
        Total memory size:                                      31.1 GiB
        Min target size:                                3.1 %  995.9 MiB
        Max target size:                               96.8 %   30.1 GiB
        Target size (adaptive):                        58.6 %   17.7 GiB
        Current size:                                  58.6 %   17.6 GiB
        Free memory size:                                        4.8 GiB
        Available memory size:                                   3.7 GiB

ARC structural breakdown (current size):                        17.6 GiB
        Compressed size:                               96.0 %   16.9 GiB
        Overhead size:                                  3.2 %  583.2 MiB
        Bonus size:                                     0.1 %   17.3 MiB
        Dnode size:                                     0.3 %   51.0 MiB
        Dbuf size:                                      0.1 %   22.5 MiB
        Header size:                                    0.3 %   53.4 MiB
        L2 header size:                                 0.0 %    0 Bytes
        ABD chunk waste size:                         < 0.1 %    2.8 MiB

ARC types breakdown (compressed + overhead):                    17.5 GiB
        Data size:                                     97.5 %   17.1 GiB
        Metadata size:                                  2.5 %  447.0 MiB

ARC states breakdown (compressed + overhead):                   17.5 GiB

root@pve:~# cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=17740847
full avg10=0.00 avg60=0.00 avg300=0.00 total=16836910

root@pve:~# free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        23Gi       3.1Gi       284Mi       4.8Gi       7.2Gi
Swap:          8.0Gi       3.5Gi       4.5Gi

And some screenshot, if that helps:
1783931370372.png
Looks like there was still plenty of memory available, correct?

Impact said:
The H610MHP seems to use a NIC that uses the e1000e driver. Have you looked into fixes for it? You also need to update your outdated UEFI. Yours is from 2022.
Click to expand...

I remember that according to this thread https://forum.proxmox.com/threads/intel-nic-e1000e-hardware-unit-hang.106001/page-6 I suspected network hangs to be the root cause of the issue so I adapted the `/etc/network/interfaces` as follows (see last line). But it did not help as we can see now.
Code: 
root@pve:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.188.3/24
        gateway 192.168.188.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0


source /etc/network/interfaces.d/*

iface eno1 inet manual
    post-up ethtool -K eno1 tso off gso off gro off

Thanks for the reminder on UEFI. Will do the update!

Edit: Regarding UEFI Update, this looks interesting. According to https://www.biostar.com.tw/app/en/mb/introduction.php?S_ID=1069&data-type=DOWNLOAD it says for "2024-08-14" BIOS: `Update microcode 0X129 to mitigate the instability of the Intel 14th /13th Gen desktop processors.` Maybe this is the fix?
 
Last edited:
Good catch on Watchtower — that was probably the trigger. But there'sone more thing in your data that stands out:

Max target size: 96.8% = 30.1 GiB

Your ARC is essentially uncapped (30 GiB on a 31 GiB host). The PVE8.1+ default of 10% never got applied on your system — probably because you upgraded from an older PVE that didn't set a limit.

The graph confirms this: after the reboot, ARC oscillates between 4and 24 GiB. A well-tuned ARC on a stable system doesn't swing like that — that's ARC and other kernel allocators fighting for pages.

I'd cap ARC explicitly. With 31 GiB total RAM and ZFS only servingdata (not LXC roots, since those live on NVMe as you mentioned), something like 4-8 GiB is plenty:

# /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8589934592 # 8 GiB
update-initramfs -u && reboot

On Impact's microcode point: intel-microcode package on Debian should already provide 0x129 for Raptor Lake. Verify with:

journalctl -k | grep -i microcode
cat /proc/cpuinfo | grep microcode | head -1

My bet: Watchtower fix + ARC cap = no more freezes. Would still do the UEFI update Impact suggested (never hurts), but I'd wait 3-4 weeks after the two fixes above before concluding they worked, given your 2-3 week freeze cycle.
 
Impact said:
I didn't mention microcode. Are you using AI to write your messages? Please don't.
Click to expand...
You're right, apologies — I misread the thread. The microcode 0x129 point came from OP's own edit citing the Biostar changelog, not from your post. My mistake, sorry.

On the AI question: yes, I've been using an LLM to help structure some of my longer replies. I still verify the technical content before posting and the diagnostic reasoning is mine.
 
OK, will try the cap fix.
Microcode shows
Code: 
root@pve:~# journalctl -k | grep -i microcode
Jul 12 16:52:32 pve kernel: microcode: Current revision: 0x0000003d
Jul 12 16:52:32 pve kernel: microcode: Updated early from: 0x00000023
root@pve:~# cat /proc/cpuinfo | grep microcode | head -1
microcode       : 0x3d

So, that means, UEFI will not bring any changes here. Microcode is already up to date.

Will report again in, let's say, 4 weeks or earlier, if there was a freeze again.
 
Yeah, of course. Will do anyway!

Edit: Done. Now let's wait and cross the fingers.
Code: 
root@pve:~# dmidecode -t bios
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
        Vendor: American Megatrends International, LLC.
        Version: 5.27
        Release Date: 05/08/2025
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 0 MB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
                Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
                5.25"/360 kB floppy services are supported (int 13h)
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 5.27

Handle 0x0004, DMI type 13, 22 bytes
BIOS Language Information
        Language Description Format: Long
        Installable Languages: 2
                en|US|iso8859-1
                zh|CN|unicode
        Currently Installed Language: en|US|iso8859-1
 
Last edited:
  • Like
Reactions: Johannes S
g.fiore said:
Good catch on Watchtower — that was probably the trigger. But there'sone more thing in your data that stands out:
Click to expand...
Drop Watchtower & Portainer, and have a look on Dockhand. Better GUI, much more Features, including Update Check for CTs .
 
You must log in or register to reply here.
Top Bottom
Back