Ryzen 7 AI 350 Framework no p-states, locked on 2 GHz, microcode security patches missing

HardcodedNonce · December 4, 2025, 9:46pm

Hi,

I have a new company issued Framework Ryzen 7 AI 350 13" Laptop but the system has problems with QubeOS i can’t really live with: pstate handling is not working and the cpu frequency is locked at 2 GHz.

This occurs at least on 4.2.4 and 4.3-rc3, the following content is from a freshly installed and fully updated 4.2.4 with all default settings.

These problems do not occur on manjaro, debian or fedora.

Also, i seem to miss important microcodes, as lscpu shows me vulnerable to something.

[root@dom0 user]# lscpu
Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             46 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      8
  On-line CPU(s) list:       0-7
Vendor ID:                   AuthenticAMD
  BIOS Vendor ID:            Advanced Micro Devices, Inc.
  Model name:                AMD Ryzen AI 7 350 w/ Radeon 860M
    BIOS Model name:         AMD Ryzen AI 7 350 w/ Radeon 860M               AMD FWTS CPU @ 2.0GHz
    BIOS CPU family:         107
    CPU family:              26
    Model:                   96
    Thread(s) per core:      1
    Core(s) per socket:      8
    Socket(s):               1
    Stepping:                0
    BogoMIPS:                3992.45
    Flags:                   fpu de tsc msr pae mce cx8 apic mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulq
                             dq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy abm sse4a misalignsse 3dnowprefetch bpext ibpb vmmcall fsgsbase bmi1 avx2 bmi2 erms avx512f a
                             vx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 avx_vnni avx512_bf16 clzero xsaveerptr arat avx512vbmi avx512_vbmi2 gfni vaes vpclmulqdq a
                             vx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm
Virtualization features:     
  Hypervisor vendor:         Xen
  Virtualization type:       none
Caches (sum of all):         
  L1d:                       384 KiB (8 instances)
  L1i:                       256 KiB (8 instances)
  L2:                        8 MiB (8 instances)
  L3:                        128 MiB (8 instances)
NUMA:                        
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-7
Vulnerabilities:             
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Mitigation; Safe RET
  Spec store bypass:         Vulnerable
  Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:                Mitigation; Retpolines; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                     Not affected
  Tsa:                       Not affected
  Tsx async abort:           Not affected

My syslog starts with a Firmware Bug Error in line 3.

Dec 04 21:26:18 dom0 kernel: Linux version 6.15.10-1.qubes.fc37.x86_64 (mockbuild@59a3b28adaf04384af036755d1590b82) (gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1), GNU ld version 2.38-27.fc37) #1 SMP PREEMPT_DYNAMIC Tue Aug>
Dec 04 21:26:18 dom0 kernel: Command line: placeholder root=/dev/mapper/qubes_dom0-root ro rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles 6.12.11-1.qubes.fc37.x86_64 x86_64 rhgb quiet r>
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: TSC doesn't count with P0 frequency!

The next part that looks off is the CPU topology. It seems to get it right at last, but i am not sure as 8 cpus are rejected?

Dec 04 21:26:18 dom0 kernel: CPU topo: CPU limit of 8 reached. Ignoring further CPUs
Dec 04 21:26:18 dom0 kernel: ACPI: X2APIC_NMI (uid[0xffffffff] high level lint[0x1])
Dec 04 21:26:18 dom0 kernel: ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
Dec 04 21:26:18 dom0 kernel: IOAPIC[0]: apic_id 33, version 33, address 0xfec00000, GSI 0-23
Dec 04 21:26:18 dom0 kernel: IOAPIC[1]: apic_id 34, version 33, address 0xfd280000, GSI 24-55
Dec 04 21:26:18 dom0 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Dec 04 21:26:18 dom0 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Dec 04 21:26:18 dom0 kernel: ACPI: Using ACPI (MADT) for SMP configuration information
Dec 04 21:26:18 dom0 kernel: ACPI: HPET id: 0x10228201 base: 0xfed00000
Dec 04 21:26:18 dom0 kernel: CPU topo: Max. logical packages:   1
Dec 04 21:26:18 dom0 kernel: CPU topo: Max. logical dies:       1
Dec 04 21:26:18 dom0 kernel: CPU topo: Max. dies per package:   1
Dec 04 21:26:18 dom0 kernel: CPU topo: Max. threads per core:   1
Dec 04 21:26:18 dom0 kernel: CPU topo: Num. cores per package:     8
Dec 04 21:26:18 dom0 kernel: CPU topo: Num. threads per package:   8
Dec 04 21:26:18 dom0 kernel: CPU topo: Allowing 8 present CPUs plus 0 hotplug CPUs
Dec 04 21:26:18 dom0 kernel: CPU topo: Rejected CPUs 8
Dec 04 21:26:18 dom0 kernel: [mem 0x7c000000-0x7d674fff] available for PCI devices
Dec 04 21:26:18 dom0 kernel: Booting kernel on Xen

Then, some checksum is wrong.

Dec 04 21:26:18 dom0 kernel: ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0xDB, should be 0x66 (20240827/utcksum-58)
Dec 04 21:26:18 dom0 kernel: clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns

and soon this:

Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   1: APIC ID mismatch. Firmware: 0x0002 APIC: 0x0001
Dec 04 21:26:18 dom0 kernel: cpu 1 spinlock event irq 97
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   2: APIC ID mismatch. Firmware: 0x0004 APIC: 0x0002
Dec 04 21:26:18 dom0 kernel: cpu 2 spinlock event irq 98
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   3: APIC ID mismatch. Firmware: 0x0006 APIC: 0x0003
Dec 04 21:26:18 dom0 kernel: cpu 3 spinlock event irq 99
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   4: APIC ID mismatch. Firmware: 0x0008 APIC: 0x0004
Dec 04 21:26:18 dom0 kernel: cpu 4 spinlock event irq 100
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   5: APIC ID mismatch. Firmware: 0x000a APIC: 0x0005
Dec 04 21:26:18 dom0 kernel: cpu 5 spinlock event irq 101
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   6: APIC ID mismatch. Firmware: 0x000c APIC: 0x0006
Dec 04 21:26:18 dom0 kernel: cpu 6 spinlock event irq 102
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: CPU   7: APIC ID mismatch. Firmware: 0x000e APIC: 0x0007
Dec 04 21:26:18 dom0 kernel: cpu 7 spinlock event irq 103

soon, there is more failing stuff, including p-states:

Dec 04 21:26:18 dom0 kernel: ACPI: button: Power Button [PWRB]
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
Dec 04 21:26:18 dom0 kernel: thermal LNXTHERM:00: registered as thermal_zone0
Dec 04 21:26:18 dom0 kernel: ACPI: thermal: Thermal Zone [TZ00] (22 C)
Dec 04 21:26:18 dom0 kernel: thermal LNXTHERM:01: registered as thermal_zone1
Dec 04 21:26:18 dom0 kernel: ACPI: thermal: Thermal Zone [TZ01] (24 C)
Dec 04 21:26:18 dom0 kernel: thermal LNXTHERM:02: registered as thermal_zone2
Dec 04 21:26:18 dom0 kernel: ACPI: thermal: Thermal Zone [TZ02] (21 C)
Dec 04 21:26:18 dom0 kernel: thermal LNXTHERM:03: registered as thermal_zone3
Dec 04 21:26:18 dom0 kernel: ACPI: thermal: Thermal Zone [TZ03] (29 C)
Dec 04 21:26:18 dom0 kernel: Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
Dec 04 21:26:18 dom0 kernel: ACPI: battery: Slot [BAT1] (battery present)
Dec 04 21:26:18 dom0 kernel: hpet_acpi_add: no address or irqs in _CRS
Dec 04 21:26:18 dom0 kernel: Non-volatile memory driver v1.3
Dec 04 21:26:18 dom0 kernel: Linux agpgart interface v0.103
Dec 04 21:26:18 dom0 kernel: tpm_crb MSFT0101:00: Disabling hwrng
Dec 04 21:26:18 dom0 kernel: ACPI: bus type drm_connector registered
Dec 04 21:26:18 dom0 kernel: usbcore: registered new interface driver usbserial_generic
Dec 04 21:26:18 dom0 kernel: usbserial: USB Serial support registered for generic
Dec 04 21:26:18 dom0 kernel: i8042: PNP: PS/2 Controller [PNP0303:KBC0] at 0x60,0x64 irq 1
Dec 04 21:26:18 dom0 kernel: i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
Dec 04 21:26:18 dom0 kernel: i8042: Warning: Keylock active
Dec 04 21:26:18 dom0 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Dec 04 21:26:18 dom0 kernel: mousedev: PS/2 mouse device common for all mice
Dec 04 21:26:18 dom0 kernel: rtc_cmos 00:01: RTC can wake from S4
Dec 04 21:26:18 dom0 kernel: rtc_cmos 00:01: registered as rtc0
Dec 04 21:26:18 dom0 kernel: rtc_cmos 00:01: setting system clock to 2025-12-04T20:26:17 UTC (1764879977)
Dec 04 21:26:18 dom0 kernel: rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram
Dec 04 21:26:18 dom0 kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Dec 04 21:26:18 dom0 kernel: device-mapper: uevent: version 1.0.3
Dec 04 21:26:18 dom0 kernel: device-mapper: ioctl: 4.49.0-ioctl (2025-01-17) initialised: dm-devel@lists.linux.dev
Dec 04 21:26:18 dom0 kernel: amd_pstate: The CPPC feature is supported but currently disabled by the BIOS.
                             Please enable it if your BIOS has the CPPC option.
Dec 04 21:26:18 dom0 kernel: amd_pstate: failed to register with return -19
Dec 04 21:26:18 dom0 kernel: sysfb: VRAM smaller than advertised
Dec 04 21:26:18 dom0 kernel: efifb: probing for efifb
Dec 04 21:26:18 dom0 kernel: efifb: No BGRT, not showing boot graphics
Dec 04 21:26:18 dom0 kernel: efifb: framebuffer at 0x5800000000, using 13536k, total 13536k
Dec 04 21:26:18 dom0 kernel: efifb: mode is 2256x1504x32, linelength=9216, pages=1
Dec 04 21:26:18 dom0 kernel: efifb: scrolling: redraw
Dec 04 21:26:18 dom0 kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Dec 04 21:26:18 dom0 kernel: fbcon: Deferring console take-over
Dec 04 21:26:18 dom0 kernel: fb0: EFI VGA frame buffer device
Dec 04 21:26:18 dom0 kernel: ccp 0000:c1:00.2: enabling device (0000 -> 0002)
Dec 04 21:26:18 dom0 kernel: xen: registering gsi 37 triggering 0 polarity 1
Dec 04 21:26:18 dom0 kernel: xen: --> pirq=37 -> irq=37 (gsi=37)
Dec 04 21:26:18 dom0 kernel: ccp 0000:c1:00.2: tee: ring init command failed (0x00000005)
Dec 04 21:26:18 dom0 kernel: ccp 0000:c1:00.2: tee: failed to init ring buffer
Dec 04 21:26:18 dom0 kernel: ccp 0000:c1:00.2: tee initialization failed
Dec 04 21:26:18 dom0 kernel: ccp 0000:c1:00.2: psp initialization failed

Do you have any tips what i could do to fix or further troubleshoot this, as this is not my area of expertise.

Is this something that should be reported as a Bug, as the laptop is not that exotic and the problems only seem to occur on QubesOS?

I found this HCL, but nothing helpful with my problem otherwise on the forum.

Thank you in advance!

corny · December 4, 2025, 11:29pm

Do you have the latest bios update from framework? AMD microcode updates works different to Intel, it’ll mostly come from bios updates not qubes updates

HardcodedNonce · December 5, 2025, 12:07am

Thanks for your answer!

I thought so, but there was a newer update, now i am up to date with 3.0.5.

Unfortunately, the same behaviour.

Other than that i

fuzzed some power-related options in the very limited UEFI, because Dec 04 21:26:18 dom0 kernel: amd_pstate: The CPPC feature is supported but currently disabled by the BIOS. Please enable it if your BIOS has the CPPC option. hinted at that, all power saving options disabled.
chased some AI hallucinations and being gaslight by it as far as i can tell.

I am not sure yet if this is a firmware, xen or linux kernel issue, but it affects xen tools too and not only dom0. Also i will update back to 4.3-rc3 as iirc it should use a newer xen version and 4.3 is close anyway.

Thank you very much for the UEFI tip, but i think you are wrong about this part:

AMD microcode updates works different to Intel, it’ll mostly come from bios updates not qubes updates

I am not into the technical implementation details, but this does not match my observation on different OSes (installed on SSD, upgraded, rebooted), lscpu reported mitigated there, so the microcode-update must have come from the OS in that cases.

corny · December 5, 2025, 12:36am

I have 9600x Ryzen (about 6-12 months older than yours) and have a couple of your issues (APIC ID and CPPC ones) however they are not causing any noticeable issues. My CPU throttles frequency correctly

I don’t know how different your CPU is (generation wise) but I would have thought the kinks in bios/microcode would have been worked out by AMD/framework by now. I’m on a desktop with MSI motherboard

Xen is supposed to have improved AMD support in 4.21 so hopefully that will get into Qubes soon

corny · December 5, 2025, 12:43am

It’s possible that I’m wrong but I’m basing it on qubes documentation

Specifically

Intel and AMD handle microcode updates differently, which has significant security implications. On Intel platforms, microcode updates can typically be loaded from the operating system. This allows the Qubes security team to respond rapidly to new vulnerabilities by shipping microcode updates alongside other security updates directly to users. By contrast, on AMD client (as opposed to server) platforms, microcode updates are typically shipped only as part of system firmware and generally cannot be loaded from the operating system 1. This means that AMD users typically must wait for:

AMD to distribute microcode updates to original equipment manufacturers (OEMs), original design manufacturers (ODMs), and motherboard manufacturers (MB); and

The user’s OEM, ODM, or MB to provide a suitable BIOS or (U)EFI update for the user’s system.

Historically, AMD has often been slow to complete step (1), at least for its client (as opposed to server) platforms 2. In some cases, AMD has made fixes available for its server platforms very shortly after a security embargo was lifted, but it did not make fixes available for client platforms facing the same vulnerability until weeks or months later. (A “security embargo” is the practice of avoiding public disclosure of a security vulnerability prior to a designated date.) By contrast, Intel has consistently made fixes available for new CPU vulnerabilities across its supported platforms very shortly after security embargoes have been lifted.

Step (2) varies by vendor. Many vendors fail to complete step (2) at all, while some others take a very long time to complete it.

The bottom line is that Qubes OS can run on AMD systems, and the Qubes and Xen security teams do their best to provide security support for AMD systems. However, without the ability to ship microcode updates, there is only so much they can do.

Scumbag · December 8, 2025, 8:57am

Marmarek commented that earlier this year that AMD at the time did release seperate (OS loadable) microcode updates for consumer hardware. But there is no official announcement/statement that they will continue to do this.

@HardcodedNonce
How did you check for CPU frequencies?
Some commands do not report boost frequencies properly. My Ryzen 7 5875U does use boost frequencies with Qubes OS. (Though it needs the AMD patches in upcoming Xen 4.21 for power saving frequencies below 2 GHz).
Use the command xenpm start 1|grep "Avg freq" to get current CPU frequencies in Dom0.

renehoj · December 8, 2025, 9:06am

It’s possible to manually update the microcode on AMD CPUs

https://forum.qubes-os.org/t/updating-amd-microcode-from-qubes-os/34485

I know 4.2 is missing some patches for AMD Zen 5 support, but I think they have been added in 4.3

corny · December 8, 2025, 10:07am

Weird, I did a bunch of AMD microcode searches in the past, somehow I missed this helpful guide

That’s awesome that I can update the microcode separate from the bios updates. MSI seems very slow with updates on my motherboard… 6 months since the last non-beta one.

renehoj · December 8, 2025, 9:01pm

@HardcodedNonce in the grub conf, try changing ucode=scan to ucode=scan,digest-check=off

Xen includes a list of valid microcode signing keys, and I don’t think it’s been updated to include the new fam1ah keys.

Without adding digest-check=off i’m getting a message No digest found for patch_id 0b404035 in xl dmesg.

When I add digest-check=off the 0xb404035 date = 2025-10-20 microcode is loaded from the amd-ucode-firmware package shipped with Qubes OS.

HardcodedNonce · December 18, 2025, 10:11pm

Thank you all very much for your input!

How did you check for CPU frequencies?

I used xenpm get-cpufreq-para and looked at xentop. While hashcat cracking a random MD5 with all cores to create load. The first command shows 2GHz or less, and xentop ist stuck a 1996 MHz.

With xenpm start 1|grep "Avg freq" i can see i clocking to 3.6 GHz and even turboing to 4.8GHz, after enabled with xenpm enable-turbo-mode.

I switched to 4.3-rc4 for further testing and didnt looked at 4.2.4 or 4.3-rc3 again, but now the p-state problem seems to not exist, but some tools output wrong values.

Regarding the missing microcodes:

Without adding digest-check=off i’m getting a message No digest found for patch_id 0b404035 in xl dmesg.

When I add digest-check=off the 0xb404035 date = 2025-10-20 microcode is loaded from the amd-ucode-firmware package shipped with Qubes OS.

On 4.3-rc4, this unfortunately does not work and all error messages in the syslog remain more or less the same. Hower my digest failures in xl dmesg went away and it loaded some ucode.

(XEN) microcode: CPU0 updated from 0xb600032 to 0xb600037, date = 2025-10-19

However, the lscpu output still reports vulnerable to spec store bypass. Maybe that is a false positive?

I have not done the firmware extraction yet, as i doubt that there is a newer version for this. I assume your lscpu reports mitigated with your, one day older microcode? But thank you very much for the great forum post about it!

I am a bit troubled by this, as it does not make much sense to me, unless the lscpu output is just wrong.

Thank you very much for your help!

renehoj · December 18, 2025, 10:32pm

The mitigation is disabled by default. Enabling it comes with a serious performance penalty, and it’s considered a minor security risk.

You can use the parameter spec-ctrl=ssbd=true if you want to enable mitigation.

https://www.qubes-os.org/news/2018/06/13/qsb-40-update/