Pillendreher

Die C-States in Corefreq sind wohl übrigens softwarebasiert, sofern ich diesen Beitrag richtig verstehe: https://github.com/cyring/CoreFreq/discussions/320#discussioncomment-8117677

Ich hab diese bisher nur in Corefreq gesehen Da hast du dann aber die seltsame Situation, dass eigentlich Corefreq alles übernimmt und nicht der P-State-Treiber.

Steht nichts besonderes drinnen.

Worin äußert sich das denn bei dir? Was zeigt er bei "cpufreq-info" an?

Kann bestätigen, dass "amd_pstate=passive" über cpufreq-info als angewandter Treiber angezeigt wird: root@Tower:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to [email protected], please. analyzing CPU 0: driver: amd-pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 2.88 GHz. analyzing CPU 1: driver: amd-pstate CPUs which run at the same hardware frequency: 1 CPUs which need to have their frequency coordinated by software: 1 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 563 MHz. analyzing CPU 2: driver: amd-pstate CPUs which run at the same hardware frequency: 2 CPUs which need to have their frequency coordinated by software: 2 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 2.14 GHz. analyzing CPU 3: driver: amd-pstate CPUs which run at the same hardware frequency: 3 CPUs which need to have their frequency coordinated by software: 3 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 2.02 GHz. analyzing CPU 4: driver: amd-pstate CPUs which run at the same hardware frequency: 4 CPUs which need to have their frequency coordinated by software: 4 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 4.44 GHz. analyzing CPU 5: driver: amd-pstate CPUs which run at the same hardware frequency: 5 CPUs which need to have their frequency coordinated by software: 5 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.45 GHz. analyzing CPU 6: driver: amd-pstate CPUs which run at the same hardware frequency: 6 CPUs which need to have their frequency coordinated by software: 6 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 3.21 GHz. analyzing CPU 7: driver: amd-pstate CPUs which run at the same hardware frequency: 7 CPUs which need to have their frequency coordinated by software: 7 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 3.55 GHz. analyzing CPU 8: driver: amd-pstate CPUs which run at the same hardware frequency: 8 CPUs which need to have their frequency coordinated by software: 8 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 3.55 GHz. analyzing CPU 9: driver: amd-pstate CPUs which run at the same hardware frequency: 9 CPUs which need to have their frequency coordinated by software: 9 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.75 GHz. analyzing CPU 10: driver: amd-pstate CPUs which run at the same hardware frequency: 10 CPUs which need to have their frequency coordinated by software: 10 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 4.44 GHz. analyzing CPU 11: driver: amd-pstate CPUs which run at the same hardware frequency: 11 CPUs which need to have their frequency coordinated by software: 11 maximum transition latency: 20.0 us. hardware limits: 400 MHz - 4.46 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, per formance, schedutil current policy: frequency should be within 400 MHz and 4.46 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 3.55 GHz. root@Tower:~# Mit allen Festplatten runtergefahren, zwei BD-Brennern (keiner aktiv) und zwei SSDs, einem 5600G, zwei RAM-Riegeln, einer Dell PERC H310 und 3x 140mm Lüftern komme ich so im Leerlauf auf ca. 35 W. Nicht so schlecht, aber auch nichts besonderes m.E.

admin:password

Got ya, now it looks like everything's fine in that regard: Is this the way it should be though? As of right now, the CPU is not run by pstate but rather by corefreq itself. I thought the whole point of this was to run pstate?

Thanks. The main culprit was "amd_pstate=passive". After removing that from syslinux.cfg, everything's missing: I can register everything now: But now the governor is missing: CPPC needs to be enabled manually and appears "green" afterwards. Seems like I'm getting slightly lower power consumption stats: Btw: How do I make all of these things persistent after reboots? I've created a corefreqk.conf in /boot/config/modprobe.d/, yet nothing changes. This is what it looks like as of right now: Idle_Route=1 Register_ClockSource=1 Register_CPU_Freq=1 Register_Governor=1 Register_CPU_Idle=1[/CODE]

So, ich greife das Thema nochmal auf nach langer Zeit Unraid-Version 6.12.3 Folgendes steht in der syslinux drinnen: nmi_watchdog=0 modprobe.blacklist=k10temp,sp5100_tco,acpi_cpufreq idle=halt nowatchdog amd_pstate=passive[/CODE] Der P-State-Treiber muss nicht mehr gesondert geladen werden. In Corefreq alles registriert bis auf den cpu-freq Treiber, der will weiterhin mit folgender Fehlermeldung nicht: Im Kernel-Fenster wird er mir mit "amd-pstate" angezeigt, was ich jetzt mal nicht als Problem ansehe: CPPC wurde ja mittlerweile in ein eigenes Fenster ausgelagert und ist aktiviert: Das TGT habe ich auf den kleinstmöglichen Wert "1" gesetzt: Die Kerne gehen mit diesen Einstellungen laut Corefreq auch in C4:C6: Die Leistungsaufnahme zeigt mir Corefreq damit im Leerlauf wie folgt an: Muss mal mein Stromverbrauchsmessgerät suchen, keine Ahnung in welcher Umzugskiste sich das versteckt hält. Vielleicht mag mal jemand seine Coreqfreq Power-Werte reinstellen um vergleichen zu können

Sicherlich, nur ist das ja immer eine Frage des konkreten Einzelfalles. Ob das Teil z.B. Schlafzustände verhindert, kann man ja so aus der Ferne nicht wirklich beurteilen/vorhersagen.

Also ich meine mich wie gesagt daran erinnern zu können, dass es letztes Jahr problemlos funktioniert hat. Aber 100 % kann ich es auch nicht sagen. Wie gesagt ob der Server dann komplett aus ist oder nicht ist mir ehrlich gesagt egal. Die 1-2 Minuten Wartezeit hat man immer. Das stimmt. Per Wireguard auf die Fritzbox und dann per Tasmota dürfte gehen. "rtcwake" funktioniert aber irgendwie im Moment nicht, obwohl ich es im UEFI auf "By OS" gestellt habe. Muss mal schauen, ob das noch irgendwie klappt. Muss erstmal schauen, was für eine FW ich da letztes Jahr draufgespielt habe. Es ging mir ja darum, dass das nicht im RAID-Modus läuft, sondern die Platten sozusagen durchschleift.

Soll heißen die kann das gar nicht? Wäre mir auch recht ehrlich gesagt; mir geht es nur darum, dass der nicht den ganzen Tag läuft, wenn ihn gar keiner nutzt. Und zur Not wecke ich ihn aus der Ferne über eine Wireguard Verbindung zur Fritzbox auf, falls doch jemand Zugriff braucht. Darf man fragen, wieso Du dem einen gegenüber viel aufgeschlossener bist?

Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: pdev=0x000000003dba6bae, slot=0000:01:00.0, previous operating state [D4] Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (15745348 kB) Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: sending diag reset !! Scheint die H310 Karte zu sein, denn im Log nach erneutem Hochfahren finde ich das: mpt2sas_cm0: LSISAS2008: FWVersion(20.00.07.00), ChipRevision(0x03), BiosVersion(00.00.00.00) EDIT: Test mit manuellem Schlafenlegen und manuellem Aufwecken Aug 31 18:43:26 Tower s3_sleep: Enter sleep mode Aug 31 18:43:27 Tower kernel: PM: suspend entry (deep) Aug 31 18:43:27 Tower kernel: Filesystems sync: 0.000 seconds Aug 31 18:43:52 Tower kernel: Freezing user space processes ... (elapsed 0.001 seconds) done. Aug 31 18:43:52 Tower kernel: OOM killer disabled. Aug 31 18:43:52 Tower kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Aug 31 18:43:52 Tower kernel: printk: Suspending console(s) (use no_console_suspend to debug) Aug 31 18:43:52 Tower kernel: sd 7:0:3:0: [sdg] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: sd 5:0:0:0: [sde] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: sd 7:0:2:0: [sdf] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: sd 5:0:0:0: [sde] Stopping disk Aug 31 18:43:52 Tower kernel: sd 7:0:1:0: [sdd] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: sd 7:0:0:0: [sdc] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: serial 00:04: disabled Aug 31 18:43:52 Tower kernel: r8169 0000:04:00.0 eth0: Link is Down Aug 31 18:43:52 Tower kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: pdev=0x0000000032215422, slot=0000:01:00.0, entering operating state Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: sending message unit reset !! Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: message unit reset: SUCCESS Aug 31 18:43:52 Tower kernel: sd 3:0:0:0: [sdb] Stopping disk Aug 31 18:43:52 Tower kernel: [drm] free PSP TMR buffer Aug 31 18:43:52 Tower kernel: bond0: (slave eth0): link status definitely down, disabling slave Aug 31 18:43:52 Tower kernel: device eth0 left promiscuous mode Aug 31 18:43:52 Tower kernel: bond0: now running without any active interface! Aug 31 18:43:52 Tower kernel: br0: port 1(bond0) entered disabled state Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: Refused to change power state from D0 to D3hot Aug 31 18:43:52 Tower kernel: xhci_hcd 0000:06:00.4: Refused to change power state from D0 to D3hot Aug 31 18:43:52 Tower kernel: ACPI: PM: Preparing to enter system sleep state S3 Aug 31 18:43:52 Tower kernel: ACPI: PM: Saving platform NVS memory Aug 31 18:43:52 Tower kernel: Disabling non-boot CPUs ... Aug 31 18:43:52 Tower kernel: smpboot: CPU 1 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 2 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 3 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 4 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 5 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 6 is now offline Aug 31 18:43:52 Tower kernel: Spectre V2 : Update user space SMT mitigation: STIBP off Aug 31 18:43:52 Tower kernel: smpboot: CPU 7 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 8 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 9 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 10 is now offline Aug 31 18:43:52 Tower kernel: smpboot: CPU 11 is now offline Aug 31 18:43:52 Tower kernel: ACPI: PM: Low-level resume complete Aug 31 18:43:52 Tower kernel: ACPI: PM: Restoring platform NVS memory Aug 31 18:43:52 Tower kernel: LVT offset 0 assigned for vector 0x400 Aug 31 18:43:52 Tower kernel: Enabling non-boot CPUs ... Aug 31 18:43:52 Tower kernel: x86: Booting SMP configuration: Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Aug 31 18:43:52 Tower kernel: microcode: CPU1: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C002: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU1 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4 Aug 31 18:43:52 Tower kernel: microcode: CPU2: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C004: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU2 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6 Aug 31 18:43:52 Tower kernel: microcode: CPU3: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C006: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU3 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 4 APIC 0x8 Aug 31 18:43:52 Tower kernel: microcode: CPU4: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C008: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU4 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 5 APIC 0xa Aug 31 18:43:52 Tower kernel: microcode: CPU5: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C00A: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU5 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 6 APIC 0x1 Aug 31 18:43:52 Tower kernel: microcode: CPU6: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C001: Found 3 idle states Aug 31 18:43:52 Tower kernel: Spectre V2 : Update user space SMT mitigation: STIBP always-on Aug 31 18:43:52 Tower kernel: CPU6 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 7 APIC 0x3 Aug 31 18:43:52 Tower kernel: microcode: CPU7: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C003: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU7 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 8 APIC 0x5 Aug 31 18:43:52 Tower kernel: microcode: CPU8: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C005: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU8 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 9 APIC 0x7 Aug 31 18:43:52 Tower kernel: microcode: CPU9: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C007: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU9 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 10 APIC 0x9 Aug 31 18:43:52 Tower kernel: microcode: CPU10: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C009: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU10 is up Aug 31 18:43:52 Tower kernel: smpboot: Booting Node 0 Processor 11 APIC 0xb Aug 31 18:43:52 Tower kernel: microcode: CPU11: patch_level=0x0a50000c Aug 31 18:43:52 Tower kernel: ACPI: \_SB_.PLTF.C00B: Found 3 idle states Aug 31 18:43:52 Tower kernel: CPU11 is up Aug 31 18:43:52 Tower kernel: ACPI: PM: Waking up from system sleep state S3 Aug 31 18:43:52 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Aug 31 18:43:52 Tower kernel: hpet: Lost 5887 RTC interrupts Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: pdev=0x0000000032215422, slot=0000:01:00.0, previous operating state [D4] Aug 31 18:43:52 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (15745348 kB) Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: sending diag reset !! Aug 31 18:43:52 Tower kernel: xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit Aug 31 18:43:52 Tower kernel: usb usb1: root hub lost power or was reset Aug 31 18:43:52 Tower kernel: usb usb2: root hub lost power or was reset Aug 31 18:43:52 Tower kernel: serial 00:04: activated Aug 31 18:43:52 Tower kernel: [drm] PCIE GART of 1024M enabled. Aug 31 18:43:52 Tower kernel: [drm] PTB located at 0x000000F400900000 Aug 31 18:43:52 Tower kernel: [drm] PSP is resuming... Aug 31 18:43:52 Tower kernel: sd 3:0:0:0: [sdb] Starting disk Aug 31 18:43:52 Tower kernel: sd 5:0:0:0: [sde] Starting disk Aug 31 18:43:52 Tower kernel: [drm] reserve 0x400000 from 0xf41f800000 for PSP TMR Aug 31 18:43:52 Tower kernel: nvme nvme0: 15/0/0 default/read/poll queues Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: RAS: optional ras ta ucode is not available Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: RAP: optional rap ta ucode is not available Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SMU is resuming... Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: dpm has been disabled Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SMU is resumed successfully! Aug 31 18:43:52 Tower kernel: [drm] DMUB hardware initialized: version=0x0101001F Aug 31 18:43:52 Tower kernel: [drm] kiq ring mec 2 pipe 1 q 0 Aug 31 18:43:52 Tower kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode). Aug 31 18:43:52 Tower kernel: [drm] JPEG decode initialized successfully. Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 1 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 1 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 1 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 1 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 1 Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: [drm] Cannot find any crtc or sizes Aug 31 18:43:52 Tower kernel: amdgpu 0000:06:00.0: [drm] Cannot find any crtc or sizes Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: Invalid host diagnostic register value Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: System Register set: Aug 31 18:43:52 Tower kernel: 00000000: ffffffff Aug 31 18:43:52 Tower kernel: 00000004: ffffffff Aug 31 18:43:52 Tower kernel: 00000008: ffffffff Aug 31 18:43:52 Tower kernel: 0000000c: ffffffff Aug 31 18:43:52 Tower kernel: 00000010: ffffffff Aug 31 18:43:52 Tower kernel: 00000014: ffffffff Aug 31 18:43:52 Tower kernel: 00000018: ffffffff Aug 31 18:43:52 Tower kernel: 0000001c: ffffffff Aug 31 18:43:52 Tower kernel: 00000020: ffffffff Aug 31 18:43:52 Tower kernel: 00000024: ffffffff Aug 31 18:43:52 Tower kernel: 00000028: ffffffff Aug 31 18:43:52 Tower kernel: 0000002c: ffffffff Aug 31 18:43:52 Tower kernel: 00000030: ffffffff Aug 31 18:43:52 Tower kernel: 00000034: ffffffff Aug 31 18:43:52 Tower kernel: 00000038: ffffffff Aug 31 18:43:52 Tower kernel: 0000003c: ffffffff Aug 31 18:43:52 Tower kernel: 00000040: ffffffff Aug 31 18:43:52 Tower kernel: 00000044: ffffffff Aug 31 18:43:52 Tower kernel: 00000048: ffffffff Aug 31 18:43:52 Tower kernel: 0000004c: ffffffff Aug 31 18:43:52 Tower kernel: 00000050: ffffffff Aug 31 18:43:52 Tower kernel: 00000054: ffffffff Aug 31 18:43:52 Tower kernel: 00000058: ffffffff Aug 31 18:43:52 Tower kernel: 0000005c: ffffffff Aug 31 18:43:52 Tower kernel: 00000060: ffffffff Aug 31 18:43:52 Tower kernel: 00000064: ffffffff Aug 31 18:43:52 Tower kernel: 00000068: ffffffff Aug 31 18:43:52 Tower kernel: 0000006c: ffffffff Aug 31 18:43:52 Tower kernel: 00000070: ffffffff Aug 31 18:43:52 Tower kernel: 00000074: ffffffff Aug 31 18:43:52 Tower kernel: 00000078: ffffffff Aug 31 18:43:52 Tower kernel: 0000007c: ffffffff Aug 31 18:43:52 Tower kernel: 00000080: ffffffff Aug 31 18:43:52 Tower kernel: 00000084: ffffffff Aug 31 18:43:52 Tower kernel: 00000088: ffffffff Aug 31 18:43:52 Tower kernel: 0000008c: ffffffff Aug 31 18:43:52 Tower kernel: 00000090: ffffffff Aug 31 18:43:52 Tower kernel: 00000094: ffffffff Aug 31 18:43:52 Tower kernel: 00000098: ffffffff Aug 31 18:43:52 Tower kernel: 0000009c: ffffffff Aug 31 18:43:52 Tower kernel: 000000a0: ffffffff Aug 31 18:43:52 Tower kernel: 000000a4: ffffffff Aug 31 18:43:52 Tower kernel: 000000a8: ffffffff Aug 31 18:43:52 Tower kernel: 000000ac: ffffffff Aug 31 18:43:52 Tower kernel: 000000b0: ffffffff Aug 31 18:43:52 Tower kernel: 000000b4: ffffffff Aug 31 18:43:52 Tower kernel: 000000b8: ffffffff Aug 31 18:43:52 Tower kernel: 000000bc: ffffffff Aug 31 18:43:52 Tower kernel: 000000c0: ffffffff Aug 31 18:43:52 Tower kernel: 000000c4: ffffffff Aug 31 18:43:52 Tower kernel: 000000c8: ffffffff Aug 31 18:43:52 Tower kernel: 000000cc: ffffffff Aug 31 18:43:52 Tower kernel: 000000d0: ffffffff Aug 31 18:43:52 Tower kernel: 000000d4: ffffffff Aug 31 18:43:52 Tower kernel: 000000d8: ffffffff Aug 31 18:43:52 Tower kernel: 000000dc: ffffffff Aug 31 18:43:52 Tower kernel: 000000e0: ffffffff Aug 31 18:43:52 Tower kernel: 000000e4: ffffffff Aug 31 18:43:52 Tower kernel: 000000e8: ffffffff Aug 31 18:43:52 Tower kernel: 000000ec: ffffffff Aug 31 18:43:52 Tower kernel: 000000f0: ffffffff Aug 31 18:43:52 Tower kernel: 000000f4: ffffffff Aug 31 18:43:52 Tower kernel: 000000f8: ffffffff Aug 31 18:43:52 Tower kernel: 000000fc: ffffffff Aug 31 18:43:52 Tower kernel: mpt2sas_cm0: diag reset: FAILED Aug 31 18:43:52 Tower kernel: mpt3sas 0000:01:00.0: PM: dpm_run_callback(): pci_pm_resume+0x0/0x7e returns -14 Aug 31 18:43:52 Tower kernel: mpt3sas 0000:01:00.0: PM: failed to resume async: error -14 Aug 31 18:43:52 Tower kernel: r8169 0000:04:00.0 eth0: Link is Down Aug 31 18:43:52 Tower kernel: ata6: SATA link down (SStatus 0 SControl 330) Aug 31 18:43:52 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Aug 31 18:43:52 Tower kernel: usb 1-6: reset high-speed USB device number 2 using xhci_hcd Aug 31 18:43:52 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 31 18:43:52 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 31 18:43:52 Tower kernel: ata1.00: configured for UDMA/133 Aug 31 18:43:52 Tower kernel: ata2.00: configured for UDMA/133 Aug 31 18:43:52 Tower kernel: usb 1-8: reset full-speed USB device number 4 using xhci_hcd Aug 31 18:43:52 Tower kernel: usb 1-7: reset high-speed USB device number 3 using xhci_hcd Aug 31 18:43:52 Tower kernel: r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx Aug 31 18:43:52 Tower kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Aug 31 18:43:52 Tower kernel: bond0: (slave eth0): making interface the new active one Aug 31 18:43:52 Tower kernel: device eth0 entered promiscuous mode Aug 31 18:43:52 Tower kernel: bond0: active interface up! Aug 31 18:43:52 Tower kernel: br0: port 1(bond0) entered blocking state Aug 31 18:43:52 Tower kernel: br0: port 1(bond0) entered forwarding state Aug 31 18:43:52 Tower kernel: ata3: found unknown device (class 0) Aug 31 18:43:52 Tower kernel: ata5: found unknown device (class 0) Aug 31 18:43:52 Tower kernel: ata5: softreset failed (device not ready) Aug 31 18:43:52 Tower kernel: ata3: softreset failed (device not ready) Aug 31 18:43:52 Tower kernel: ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 31 18:43:52 Tower kernel: ata5.00: configured for UDMA/133 Aug 31 18:43:52 Tower kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 31 18:43:52 Tower kernel: ata3.00: configured for UDMA/133 Aug 31 18:43:52 Tower kernel: OOM killer enabled. Aug 31 18:43:52 Tower dhcpcd[1153]: br0: carrier lost Aug 31 18:43:52 Tower kernel: Restarting tasks ... done. Aug 31 18:43:52 Tower kernel: random: crng reseeded on system resumption Aug 31 18:43:52 Tower kernel: video LNXVIDEO:00: Restoring backlight state Aug 31 18:43:52 Tower kernel: PM: suspend exit Aug 31 18:43:52 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'MARKUS-DESKTOP.local' 2>&1) took longer than 10s! Aug 31 18:43:52 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'MARKUS-DESKTOP.local' 2>&1) took longer than 10s! Aug 31 18:43:52 Tower dhcpcd[1153]: br0: deleting address 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0/64 Aug 31 18:43:52 Tower avahi-daemon[7686]: Withdrawing address record for 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0 on br0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Leaving mDNS multicast group on interface br0.IPv6 with address 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Joining mDNS multicast group on interface br0.IPv6 with address fe80::b432:c9ff:fe28:2bd0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Registering new address record for fe80::b432:c9ff:fe28:2bd0 on br0.*. Aug 31 18:43:52 Tower dhcpcd[1153]: br0: deleting route to 2a02:810d:1ec0:519c::/64 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: deleting default route via fe80::de15:c8ff:fef5:8cdd Aug 31 18:43:52 Tower avahi-daemon[7686]: Withdrawing address record for 192.168.188.24 on br0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.188.24. Aug 31 18:43:52 Tower dhcpcd[1153]: br0: deleting route to 192.168.188.0/24 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: deleting default route via 192.168.188.1 Aug 31 18:43:52 Tower avahi-daemon[7686]: Interface br0.IPv4 no longer relevant for mDNS. Aug 31 18:43:52 Tower dhcpcd[1153]: br0: carrier acquired Aug 31 18:43:52 Tower dhcpcd[1153]: br0: IAID c2:93:8f:d1 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: rebinding lease of 192.168.188.24 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: probing address 192.168.188.24/24 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: soliciting an IPv6 router Aug 31 18:43:52 Tower dhcpcd[1153]: br0: Router Advertisement from fe80::de15:c8ff:fef5:8cdd Aug 31 18:43:52 Tower dhcpcd[1153]: br0: adding address 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0/64 Aug 31 18:43:52 Tower avahi-daemon[7686]: Leaving mDNS multicast group on interface br0.IPv6 with address fe80::b432:c9ff:fe28:2bd0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Joining mDNS multicast group on interface br0.IPv6 with address 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0. Aug 31 18:43:52 Tower avahi-daemon[7686]: Registering new address record for 2a02:810d:1ec0:519c:b432:c9ff:fe28:2bd0 on br0.*. Aug 31 18:43:52 Tower avahi-daemon[7686]: Withdrawing address record for fe80::b432:c9ff:fe28:2bd0 on br0. Aug 31 18:43:52 Tower dhcpcd[1153]: br0: adding route to 2a02:810d:1ec0:519c::/64 Aug 31 18:43:52 Tower dhcpcd[1153]: br0: adding default route via fe80::de15:c8ff:fef5:8cdd Aug 31 18:43:52 Tower dhcpcd[1153]: br0: requesting DHCPv6 information Aug 31 18:43:53 Tower ntpd[1400]: Deleting interface #4 br0, 192.168.188.24#123, interface stats: received=0, sent=0, dropped=0, active_time=438 secs Aug 31 18:43:54 Tower dhcpcd[1153]: br0: REPLY6 received from fe80::de15:c8ff:fef5:8cdd Aug 31 18:43:54 Tower dhcpcd[1153]: br0: refresh in 86400 seconds Aug 31 18:43:57 Tower dhcpcd[1153]: br0: leased 192.168.188.24 for 864000 seconds Aug 31 18:43:57 Tower avahi-daemon[7686]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.188.24. Aug 31 18:43:57 Tower avahi-daemon[7686]: New relevant interface br0.IPv4 for mDNS. Aug 31 18:43:57 Tower dhcpcd[1153]: br0: adding route to 192.168.188.0/24 Aug 31 18:43:57 Tower avahi-daemon[7686]: Registering new address record for 192.168.188.24 on br0.IPv4. Aug 31 18:43:57 Tower dhcpcd[1153]: br0: adding default route via 192.168.188.1 Aug 31 18:43:59 Tower ntpd[1400]: Listen normally on 5 br0 192.168.188.24:123 Aug 31 18:43:59 Tower ntpd[1400]: new interface(s) found: waking up resolver Ich sehe dieselben Fehler wie vorhin. Und wieder kann ich auf dieselben Laufwerke nicht zugreifen. Der H310 wacht nicht auf, oder missinterpretiere ich hier etwas?

Hallo zusammen, ich habe letzte Woche meinen Server in ein neues Gehäuse verfrachtet und dabei die Dell H310 Karte sowie zwei Blu-Ray Brenner (ehemals aus meinem Desktop-System) eingebaut. Da mir zudem letztens eine Platte abgeraucht ist, muss ich etliche Blu-Rays erneut einlesen und auf der Ersatzplatte speichern. Gestern und heute hatte ich nun ein seltsames Problem: Den Server habe ich über das S3 Sleep Plugin so konfiguriert, dass er gg 0:15 schlafen geht und 10h später wieder aufwacht. Also ich vorhin zur Tür reingekommen bin, wollte ich die ersten Blu-Rays zum Einlesen und Abspeichern in den Server einlegen. Gesagt, getan: MakeMKV begann mit dem Speichervorgang. Ausgabeordner ist der Share "Serien", welchem ich eine SanDisk Ultra 3D 2TB SSD als Cache vorgeschaltet habe. Diese ist soweit ersichtlich auch voll funktionstüchtig; jedenfalls hatte ich bisher keine Probleme damit. Jedenfalls hatte ich gerade eben dasselbe Problem wie gestern: Der Speichervorgang bricht nach ein paar Sekunden ab und das System verfällt in einen seltsamen Zustand: Ich kann zwar weiterhin auf das WebUI zugreifen und kann auch über SSH Befehle ausführen, aber wenn es darum geht, auf die Laufwerke zuzugreifen, geraten Befehle in eine Endloßschleife. Ein Neustart klappt nicht, genausowenig ein Herunterfahren. Es sieht für mich so aus, als wäre die SanDisk SSD (die auch am Dell H310 hängt) irgendwie "eingefroren": Docker laufen zwar weiter (Appdata liegt auf einer Kingston A2000 SSD), aber mir scheint dass alles, was mit der SanDisk SSD zu tun hat, irgendwie im Nirgendwo landet Über smartctl -a kann ich alle Laufwerke abprüfen AUßER der SanDisk SSD und drei der Festplatten; da vier Laufwerke am H310 angeschlossen sind, liegt die Vermutung nahe, dass es sich genau um diese Platten handelt Genau hier hängt auch das Erstellen von Diagnosedaten: smartctl -x '/dev/sr1' 2>/dev/null|todos >'/tower-diagnostics-20220831-1806/smart/ASUS_BW-16D1HT_KLZL4JA1807-20220831-1806 (sr1).txt' smartctl -x '/dev/sr0' 2>/dev/null|todos >'/tower-diagnostics-20220831-1806/smart/HL-DT-ST_BD-RE_WH16NS60_KE4IA7I1136-20220831-1806 (sr0).txt' smartctl -x '/dev/sdc' 2>/dev/null|todos >'/tower-diagnostics-20220831-1806/smart/SanDisk_SDSSDH3_2T00_20234M448509-20220831-1806 cache-sandisk (sdc).txt' Und es geht nicht mehr weiter. Der Server ist für meine Begriffe nach dem Aufwachen nicht "defekt", denn zumindest kann ich Docker starten und ihn über das WebUI ansprechen. Da ich aber an beiden Tagen direkt nach dem "Erstkontakt" die Blu-Ray Laufwerke angeschmissen habe, kann ich nicht sagen, ob er anderweitig normal funktionierte. So sieht das System-Log aus seit dem letzten Einschlafen und Aufwachen: Aug 31 00:06:38 Tower kernel: PM: suspend entry (deep) Aug 31 00:06:38 Tower kernel: Filesystems sync: 0.000 seconds Aug 31 17:06:57 Tower kernel: Freezing user space processes ... (elapsed 0.001 seconds) done. Aug 31 17:06:57 Tower kernel: OOM killer disabled. Aug 31 17:06:57 Tower kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Aug 31 17:06:57 Tower kernel: printk: Suspending console(s) (use no_console_suspend to debug) Aug 31 17:06:57 Tower kernel: CoreFreq: Suspend(2:8:-1) Aug 31 17:06:57 Tower kernel: sd 7:0:3:0: [sdg] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: sd 7:0:2:0: [sdf] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: sd 5:0:0:0: [sdd] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: sd 7:0:1:0: [sde] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: sd 7:0:0:0: [sdc] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: serial 00:04: disabled Aug 31 17:06:57 Tower kernel: r8169 0000:04:00.0 eth0: Link is Down Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: pdev=0x000000003dba6bae, slot=0000:01:00.0, entering operating state Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: sending message unit reset !! Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: message unit reset: SUCCESS Aug 31 17:06:57 Tower kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache Aug 31 17:06:57 Tower kernel: [drm] free PSP TMR buffer Aug 31 17:06:57 Tower kernel: bond0: (slave eth0): link status definitely down, disabling slave Aug 31 17:06:57 Tower kernel: device eth0 left promiscuous mode Aug 31 17:06:57 Tower kernel: bond0: now running without any active interface! Aug 31 17:06:57 Tower kernel: br0: port 1(bond0) entered disabled state Aug 31 17:06:57 Tower kernel: sd 5:0:0:0: [sdd] Stopping disk Aug 31 17:06:57 Tower kernel: sd 3:0:0:0: [sdb] Stopping disk Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: Refused to change power state from D0 to D3hot Aug 31 17:06:57 Tower kernel: xhci_hcd 0000:06:00.4: Refused to change power state from D0 to D3hot Aug 31 17:06:57 Tower kernel: ACPI: PM: Preparing to enter system sleep state S3 Aug 31 17:06:57 Tower kernel: ACPI: PM: Saving platform NVS memory Aug 31 17:06:57 Tower kernel: Disabling non-boot CPUs ... Aug 31 17:06:57 Tower kernel: smpboot: CPU 1 is now offline Aug 31 17:06:57 Tower crond[1422]: time disparity of 1020 minutes detected Aug 31 17:06:57 Tower kernel: smpboot: CPU 2 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 3 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 4 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 5 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 6 is now offline Aug 31 17:06:57 Tower kernel: Spectre V2 : Update user space SMT mitigation: STIBP off Aug 31 17:06:57 Tower kernel: smpboot: CPU 7 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 8 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 9 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 10 is now offline Aug 31 17:06:57 Tower kernel: smpboot: CPU 11 is now offline Aug 31 17:06:57 Tower kernel: ACPI: PM: Low-level resume complete Aug 31 17:06:57 Tower kernel: ACPI: PM: Restoring platform NVS memory Aug 31 17:06:57 Tower kernel: LVT offset 0 assigned for vector 0x400 Aug 31 17:06:57 Tower kernel: Enabling non-boot CPUs ... Aug 31 17:06:57 Tower kernel: x86: Booting SMP configuration: Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Aug 31 17:06:57 Tower kernel: microcode: CPU1: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C002: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU1 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4 Aug 31 17:06:57 Tower kernel: microcode: CPU2: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C004: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU2 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6 Aug 31 17:06:57 Tower kernel: microcode: CPU3: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C006: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU3 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 4 APIC 0x8 Aug 31 17:06:57 Tower kernel: microcode: CPU4: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C008: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU4 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 5 APIC 0xa Aug 31 17:06:57 Tower kernel: microcode: CPU5: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C00A: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU5 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 6 APIC 0x1 Aug 31 17:06:57 Tower kernel: microcode: CPU6: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C001: Found 3 idle states Aug 31 17:06:57 Tower kernel: Spectre V2 : Update user space SMT mitigation: STIBP always-on Aug 31 17:06:57 Tower kernel: CPU6 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 7 APIC 0x3 Aug 31 17:06:57 Tower kernel: microcode: CPU7: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C003: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU7 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 8 APIC 0x5 Aug 31 17:06:57 Tower kernel: microcode: CPU8: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C005: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU8 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 9 APIC 0x7 Aug 31 17:06:57 Tower kernel: microcode: CPU9: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C007: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU9 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 10 APIC 0x9 Aug 31 17:06:57 Tower kernel: microcode: CPU10: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C009: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU10 is up Aug 31 17:06:57 Tower kernel: smpboot: Booting Node 0 Processor 11 APIC 0xb Aug 31 17:06:57 Tower kernel: microcode: CPU11: patch_level=0x0a50000c Aug 31 17:06:57 Tower kernel: ACPI: \_SB_.PLTF.C00B: Found 3 idle states Aug 31 17:06:57 Tower kernel: CPU11 is up Aug 31 17:06:57 Tower kernel: ACPI: PM: Waking up from system sleep state S3 Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: pdev=0x000000003dba6bae, slot=0000:01:00.0, previous operating state [D4] Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (15745348 kB) Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: sending diag reset !! Aug 31 17:06:57 Tower kernel: xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit Aug 31 17:06:57 Tower kernel: usb usb1: root hub lost power or was reset Aug 31 17:06:57 Tower kernel: usb usb2: root hub lost power or was reset Aug 31 17:06:57 Tower kernel: hpet: Lost 195 RTC interrupts Aug 31 17:06:57 Tower kernel: [drm] PCIE GART of 1024M enabled. Aug 31 17:06:57 Tower kernel: [drm] PTB located at 0x000000F400900000 Aug 31 17:06:57 Tower kernel: [drm] PSP is resuming... Aug 31 17:06:57 Tower kernel: serial 00:04: activated Aug 31 17:06:57 Tower kernel: sd 3:0:0:0: [sdb] Starting disk Aug 31 17:06:57 Tower kernel: sd 5:0:0:0: [sdd] Starting disk Aug 31 17:06:57 Tower kernel: [drm] reserve 0x400000 from 0xf41f800000 for PSP TMR Aug 31 17:06:57 Tower kernel: nvme nvme0: 15/0/0 default/read/poll queues Aug 31 17:06:57 Tower kernel: r8169 0000:04:00.0 eth0: Link is Down Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: RAS: optional ras ta ucode is not available Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: RAP: optional rap ta ucode is not available Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SMU is resuming... Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: dpm has been disabled Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: SMU is resumed successfully! Aug 31 17:06:57 Tower kernel: [drm] DMUB hardware initialized: version=0x0101001F Aug 31 17:06:57 Tower kernel: [drm] kiq ring mec 2 pipe 1 q 0 Aug 31 17:06:57 Tower kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode). Aug 31 17:06:57 Tower kernel: [drm] JPEG decode initialized successfully. Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 1 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 1 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 1 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 1 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 1 Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: [drm] Cannot find any crtc or sizes Aug 31 17:06:57 Tower kernel: amdgpu 0000:06:00.0: [drm] Cannot find any crtc or sizes Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: Invalid host diagnostic register value Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: System Register set: Aug 31 17:06:57 Tower kernel: 00000000: ffffffff Aug 31 17:06:57 Tower kernel: 00000004: ffffffff Aug 31 17:06:57 Tower kernel: 00000008: ffffffff Aug 31 17:06:57 Tower kernel: 0000000c: ffffffff Aug 31 17:06:57 Tower kernel: 00000010: ffffffff Aug 31 17:06:57 Tower kernel: 00000014: ffffffff Aug 31 17:06:57 Tower kernel: 00000018: ffffffff Aug 31 17:06:57 Tower kernel: 0000001c: ffffffff Aug 31 17:06:57 Tower kernel: 00000020: ffffffff Aug 31 17:06:57 Tower kernel: 00000024: ffffffff Aug 31 17:06:57 Tower kernel: 00000028: ffffffff Aug 31 17:06:57 Tower kernel: 0000002c: ffffffff Aug 31 17:06:57 Tower kernel: 00000030: ffffffff Aug 31 17:06:57 Tower kernel: 00000034: ffffffff Aug 31 17:06:57 Tower kernel: 00000038: ffffffff Aug 31 17:06:57 Tower kernel: 0000003c: ffffffff Aug 31 17:06:57 Tower kernel: 00000040: ffffffff Aug 31 17:06:57 Tower kernel: 00000044: ffffffff Aug 31 17:06:57 Tower kernel: 00000048: ffffffff Aug 31 17:06:57 Tower kernel: 0000004c: ffffffff Aug 31 17:06:57 Tower kernel: 00000050: ffffffff Aug 31 17:06:57 Tower kernel: 00000054: ffffffff Aug 31 17:06:57 Tower kernel: 00000058: ffffffff Aug 31 17:06:57 Tower kernel: 0000005c: ffffffff Aug 31 17:06:57 Tower kernel: 00000060: ffffffff Aug 31 17:06:57 Tower kernel: 00000064: ffffffff Aug 31 17:06:57 Tower kernel: 00000068: ffffffff Aug 31 17:06:57 Tower kernel: 0000006c: ffffffff Aug 31 17:06:57 Tower kernel: 00000070: ffffffff Aug 31 17:06:57 Tower kernel: 00000074: ffffffff Aug 31 17:06:57 Tower kernel: 00000078: ffffffff Aug 31 17:06:57 Tower kernel: 0000007c: ffffffff Aug 31 17:06:57 Tower kernel: 00000080: ffffffff Aug 31 17:06:57 Tower kernel: 00000084: ffffffff Aug 31 17:06:57 Tower kernel: 00000088: ffffffff Aug 31 17:06:57 Tower kernel: 0000008c: ffffffff Aug 31 17:06:57 Tower kernel: 00000090: ffffffff Aug 31 17:06:57 Tower kernel: 00000094: ffffffff Aug 31 17:06:57 Tower kernel: 00000098: ffffffff Aug 31 17:06:57 Tower kernel: 0000009c: ffffffff Aug 31 17:06:57 Tower kernel: 000000a0: ffffffff Aug 31 17:06:57 Tower kernel: 000000a4: ffffffff Aug 31 17:06:57 Tower kernel: 000000a8: ffffffff Aug 31 17:06:57 Tower kernel: 000000ac: ffffffff Aug 31 17:06:57 Tower kernel: 000000b0: ffffffff Aug 31 17:06:57 Tower kernel: 000000b4: ffffffff Aug 31 17:06:57 Tower kernel: 000000b8: ffffffff Aug 31 17:06:57 Tower kernel: 000000bc: ffffffff Aug 31 17:06:57 Tower kernel: 000000c0: ffffffff Aug 31 17:06:57 Tower kernel: 000000c4: ffffffff Aug 31 17:06:57 Tower kernel: 000000c8: ffffffff Aug 31 17:06:57 Tower kernel: 000000cc: ffffffff Aug 31 17:06:57 Tower kernel: 000000d0: ffffffff Aug 31 17:06:57 Tower kernel: 000000d4: ffffffff Aug 31 17:06:57 Tower kernel: 000000d8: ffffffff Aug 31 17:06:57 Tower kernel: 000000dc: ffffffff Aug 31 17:06:57 Tower kernel: 000000e0: ffffffff Aug 31 17:06:57 Tower kernel: 000000e4: ffffffff Aug 31 17:06:57 Tower kernel: 000000e8: ffffffff Aug 31 17:06:57 Tower kernel: 000000ec: ffffffff Aug 31 17:06:57 Tower kernel: 000000f0: ffffffff Aug 31 17:06:57 Tower kernel: 000000f4: ffffffff Aug 31 17:06:57 Tower kernel: 000000f8: ffffffff Aug 31 17:06:57 Tower kernel: 000000fc: ffffffff Aug 31 17:06:57 Tower kernel: mpt2sas_cm0: diag reset: FAILED Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: PM: dpm_run_callback(): pci_pm_resume+0x0/0x7e returns -14 Aug 31 17:06:57 Tower kernel: mpt3sas 0000:01:00.0: PM: failed to resume async: error -14 Aug 31 17:06:57 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Aug 31 17:06:57 Tower kernel: ata6: SATA link down (SStatus 0 SControl 330) Aug 31 17:06:57 Tower kernel: usb 1-6: reset high-speed USB device number 2 using xhci_hcd Aug 31 17:06:57 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 31 17:06:57 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 31 17:06:57 Tower kernel: ata1.00: configured for UDMA/133 Aug 31 17:06:57 Tower kernel: ata2.00: configured for UDMA/133 Aug 31 17:06:57 Tower kernel: usb 1-7: reset high-speed USB device number 3 using xhci_hcd Aug 31 17:06:57 Tower kernel: usb 1-8: reset full-speed USB device number 4 using xhci_hcd Aug 31 17:06:57 Tower kernel: CoreFreq: Resume(2:8:-1) Aug 31 17:06:57 Tower kernel: Scheduler frequency invariance went wobbly, disabling! Aug 31 17:06:57 Tower kernel: r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx Aug 31 17:06:57 Tower kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Aug 31 17:06:57 Tower kernel: bond0: (slave eth0): making interface the new active one Aug 31 17:06:57 Tower kernel: device eth0 entered promiscuous mode Aug 31 17:06:57 Tower kernel: bond0: active interface up! Aug 31 17:06:57 Tower kernel: br0: port 1(bond0) entered blocking state Aug 31 17:06:57 Tower kernel: br0: port 1(bond0) entered forwarding state Aug 31 17:06:57 Tower kernel: ata3: found unknown device (class 0) Aug 31 17:06:57 Tower kernel: ata5: found unknown device (class 0) Aug 31 17:06:57 Tower kernel: ata5: softreset failed (device not ready) Aug 31 17:06:57 Tower kernel: ata3: softreset failed (device not ready) Aug 31 17:06:57 Tower kernel: ata5: found unknown device (class 0) Aug 31 17:06:57 Tower kernel: ata3: found unknown device (class 0) Aug 31 17:06:57 Tower kernel: ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 31 17:06:57 Tower kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 31 17:06:57 Tower kernel: ata3.00: configured for UDMA/133 Aug 31 17:06:57 Tower kernel: ata5.00: configured for UDMA/133 Aug 31 17:06:57 Tower kernel: OOM killer enabled. Aug 31 17:06:57 Tower kernel: Restarting tasks ... done. Aug 31 17:06:57 Tower kernel: random: crng reseeded on system resumption Aug 31 17:06:57 Tower kernel: video LNXVIDEO:00: Restoring backlight state Aug 31 17:06:57 Tower kernel: PM: suspend exit Aug 31 17:06:57 Tower dhcpcd[1153]: br0: carrier lost Aug 31 17:06:57 Tower dhcpcd[1153]: br0: deleting address 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da/64 Aug 31 17:06:57 Tower avahi-daemon[10845]: Withdrawing address record for 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da on br0. Aug 31 17:06:57 Tower avahi-daemon[10845]: Leaving mDNS multicast group on interface br0.IPv6 with address 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da. Aug 31 17:06:57 Tower avahi-daemon[10845]: Joining mDNS multicast group on interface br0.IPv6 with address fe80::9c23:f7ff:fe7e:d4da. Aug 31 17:06:57 Tower avahi-daemon[10845]: Registering new address record for fe80::9c23:f7ff:fe7e:d4da on br0.*. Aug 31 17:06:57 Tower dhcpcd[1153]: br0: deleting route to 2a02:810d:1ec0:519c::/64 Aug 31 17:06:57 Tower dhcpcd[1153]: br0: deleting default route via fe80::de15:c8ff:fef5:8cdd Aug 31 17:06:57 Tower avahi-daemon[10845]: Withdrawing address record for 192.168.188.24 on br0. Aug 31 17:06:57 Tower avahi-daemon[10845]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.188.24. Aug 31 17:06:57 Tower avahi-daemon[10845]: Interface br0.IPv4 no longer relevant for mDNS. Aug 31 17:06:57 Tower dhcpcd[1153]: br0: deleting route to 192.168.188.0/24 Aug 31 17:06:57 Tower dhcpcd[1153]: br0: deleting default route via 192.168.188.1 Aug 31 17:06:57 Tower dhcpcd[1153]: br0: carrier acquired Aug 31 17:06:57 Tower dhcpcd[1153]: br0: IAID c2:93:8f:d1 Aug 31 17:06:58 Tower dhcpcd[1153]: br0: soliciting an IPv6 router Aug 31 17:06:58 Tower dhcpcd[1153]: br0: Router Advertisement from fe80::de15:c8ff:fef5:8cdd Aug 31 17:06:58 Tower dhcpcd[1153]: br0: adding address 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da/64 Aug 31 17:06:58 Tower avahi-daemon[10845]: Leaving mDNS multicast group on interface br0.IPv6 with address fe80::9c23:f7ff:fe7e:d4da. Aug 31 17:06:58 Tower avahi-daemon[10845]: Joining mDNS multicast group on interface br0.IPv6 with address 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da. Aug 31 17:06:58 Tower avahi-daemon[10845]: Registering new address record for 2a02:810d:1ec0:519c:9c23:f7ff:fe7e:d4da on br0.*. Aug 31 17:06:58 Tower avahi-daemon[10845]: Withdrawing address record for fe80::9c23:f7ff:fe7e:d4da on br0. Aug 31 17:06:58 Tower dhcpcd[1153]: br0: adding route to 2a02:810d:1ec0:519c::/64 Aug 31 17:06:58 Tower dhcpcd[1153]: br0: adding default route via fe80::de15:c8ff:fef5:8cdd Aug 31 17:06:58 Tower dhcpcd[1153]: br0: requesting DHCPv6 information Aug 31 17:06:59 Tower dhcpcd[1153]: br0: rebinding lease of 192.168.188.24 Aug 31 17:06:59 Tower dhcpcd[1153]: br0: probing address 192.168.188.24/24 Aug 31 17:06:59 Tower dhcpcd[1153]: br0: REPLY6 received from fe80::de15:c8ff:fef5:8cdd Aug 31 17:06:59 Tower dhcpcd[1153]: br0: refresh in 86400 seconds Aug 31 17:07:01 Tower ntpd[1402]: Deleting interface #16 br0, 192.168.188.24#123, interface stats: received=0, sent=0, dropped=0, active_time=2078 secs Aug 31 17:07:04 Tower dhcpcd[1153]: br0: leased 192.168.188.24 for 864000 seconds Aug 31 17:07:04 Tower avahi-daemon[10845]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.188.24. Aug 31 17:07:04 Tower avahi-daemon[10845]: New relevant interface br0.IPv4 for mDNS. Aug 31 17:07:04 Tower avahi-daemon[10845]: Registering new address record for 192.168.188.24 on br0.IPv4. Aug 31 17:07:04 Tower dhcpcd[1153]: br0: adding route to 192.168.188.0/24 Aug 31 17:07:04 Tower dhcpcd[1153]: br0: adding default route via 192.168.188.1 Aug 31 17:07:06 Tower ntpd[1402]: Listen normally on 17 br0 192.168.188.24:123 Aug 31 17:07:06 Tower ntpd[1402]: new interface(s) found: waking up resolver Aug 31 17:08:17 Tower sshd[23293]: Read error from remote host 192.168.188.21 port 1598: Connection timed out Aug 31 17:08:17 Tower sshd[23293]: pam_unix(sshd:session): session closed for user root Aug 31 17:08:17 Tower elogind-daemon[1373]: Removed session c8. Aug 31 17:32:09 Tower ntpd[1402]: no peer for too long, server running free now Aug 31 17:59:55 Tower webGUI: Unsuccessful login user root from 192.168.188.21 Aug 31 17:59:59 Tower webGUI: Successful login user root from 192.168.188.21 Und so sieht man Befehl für die Zeit nach dem Aufwachvorgang im S3 Plugin aus: sleep 120; hdparm -y $(ls /dev/sd*|grep "[a-z]$") >/dev/null 2>&1 Was mir in den letzten Tagen noch aufgefallen war: Warum auch immer wird mir die SanDisk SSD ab und zu im WebUI als "grau" angezeigt. Wird die vielleicht auch mit einem spindown-Befehl versorgt und landet so in einem Art unzulässigen Zustand, aus welchem sie so nicht mehr aufwachen kann? Das System kann ich im Übrigen nur per "Strom aus" aus diesem Zustand befreien. Nach einem erneuten Hochfahren läuft auch alles problemlos. Wo kann ich hier ansetzen? Ich vermute ja, dass es die H310 Karte ist, die dieses Problem versursacht, wüsste jetzt aber ehrlich gesagt nicht, woher das plötzlich kommen sollte, denn im letzten Jahr hatte ich sie bereits im Einsatz und dort nie Probleme mit dem Aufwachen aus S3?!

Not much. I just enabled C-States in my UEFI, enabled C6 in corefreq and switched the CPPC Target to "1". That's all!

It says that the p-state driver is the current CPU-Freq driver: I'll try not loading it at boot, maybe that will help. EDIT: So now that everything is missing, I can successfully register everything via corefreq (Still can't enable HSMP though): Although now the Governor driver seems to be missing, which - I assume - isn't good.

Which means? Is something missing in my UEFI settings? I'll give the other options a try. Both are already enabled. Unfortunately, I can't enable "HSMP". It's currently set to "off": Yet when I try to enable it, nothing happens: And the CPU-Freq driver still can't be enabled either: I've put it at "1" (99,81 MHz): Compared to what I posted yesterday (7.4 W total), I'm now at 4,74 W total in this screenshot - nice improvement PS: What is "absolute frequency" in this setting? It's much higher than the accumulated cores' frequencies?

Ich hab mir letztes Jahr ein Dell H310 gebraucht besorgt und dieses dann so "umgeflasht", dass es die angeschlossenen Platten 1-zu-1 an Unraid weitergibt (mir fällt der Begriff gerade nicht ein; da gibt es soweit ich mich erinnern kann zwei verschiedene Betriebsmodi). Das wäre vielleicht was für dich? Hatte mich vor nem Jahr gut 50 € gekostet.

I can go all the way down to C6 now actually: And the frequency dashboard actually shows the cores reaching C6: Powerdraw is basically identical though compared to the previous configuration:

OK, so the first line (with a "modprobe amd-pstate" attached to it) lets me register the Idle-driver. Yet now I can't register the freq-driver:

OK, so I've installed the latest version (Danke @ich777!) and tried registering everything. This is as far as I got: This is what happens when trying to register the Idle driver: This is what the Kernel data looks like: PS: Idle Limit C3? Any way to change that? Also, it looks like the CPU is never quite leaving C1: Anyway, this is the core power draw in idle: And now the CPPC "ranges" are set to auto:

@CyrIng OK, so this is what corefreq looks like after passing the following kernel parameters: Here it loos like corefreq doesn't recognize the P-State driver: Yet here, P-State is mentioned: And this is what the frequency-window looks like after "activating" CCP in the "Performance Monitoring" window: This does looks weird, doesn't it? "Min" higher than "Max"? Seems something's off:

So, mal kurze Frage: Sind diese Werte nach ca. 43h laufendem Server bedenkenswert? Sieht schon nach viel aus, oder?

Trying to simply switch to the Cezanne APU is resulting in a failed attempt for me: I can't RDP to the VM anymore after making the switch with this being the last log message: 2022-08-16T16:20:02.284507Z qemu-system-x86_64: -device vfio-pci,host=0000:04:00.0,id=hostdev0,bus=pci.4,addr=0x0: Failed to mmap 0000:04:00.0 BAR 0. Performance may be slow I'll go through this thread again and will give it another try.

In der Original-Meldung klingt das zumindest so, als handele es sich nur um Anpassungen am Treiber und nicht um einen neuen o.ä.: https://www.phoronix.com/news/AMD-P-State-Update-But-Miss-6.0 Recently AMD has been working on precision boost control and other fixes to AMD P-State and that's the patches revised today. Those patches for the precision boost hardware control and fixes were sent out today in their fifth revision. EDIT: In den Kommentaren wird auf diesen Diskussionsfaden verwiesen: https://forum.endeavouros.com/t/how-to-use-amd-p-state-in-linux-5-17/25247 Schau ich mir auch mal an.