Intel PMC Telemetry Kernel Panic

User Support Hardware Issues
1

Hi,

first ever Qubes forum post.
I recently got my hands on a new laptop with an Intel Core Ultra 275HX. This (according to Intel documentation) has S3 sleep support. This support relies on the intel_pmc_ssram_telemetry driver which was recently moved out of intel_pmc_core. Without the telemetry driver, core won’t load and i am unable to suspend correctly.

Upon booting with i am greeted with a pretty much invisible error. Sometimes i catch it in the debug messages, other times the screen goes blank right before.

If i understand correctly, the telemetry driver tries to access some page in memory, which does not exist, causing xen to try to update the mappings from the mmu. I am not sure what exactly is responsible for the panic at this point.

All i know is that i need to blacklist the intel_pmc_ssram_telemetry driver for my system to boot correctly.
This issue does exist on the stable, devel and latest kernel of qubes and it does not exist on a simple fedora installation with the same kernel versions.
So I am pretty sure it is a xen related issue. I have yet to find any other references to this issue except people saying to just disable that module which sadly is not a workable solution for me.

Any help or ideas would be great because i am slowly running out of things to try.
The failing boot was done using the default qubes and xen parameters and loglevel=8.

The rest of this hardware is great and i would love to get this fixed but i could not find anything useful regarding this problem anywhere online.

2

Welcome LCzDQv,

I have the same problem on my machine, but simply blacklisting works fine for me. But as I had some time on my hands looked a bit further into this.

It seems that this is a XEN vs direct hardware issue. I’ve found this commit that addresses this issue (or one like it); but it seems it did not carry over to the new driver.

You could start the investigation to see if this pattern appears in the new driver.

Kind regards, Bloged

3

Hi,

thanks for your reply. The link you posted seem to be a link to this issue post.

Best regards

4

I’ve gotten the kernel log from journalctl and this is the relevant stacktrace:

Aug 30 22:59:46 dom0 kernel: intel_pmc_ssram_telemetry 0000:00:14.0: enabling device (0000 -> 0002)
Aug 30 22:59:46 dom0 kernel: ------------[ cut here ]------------
Aug 30 22:59:46 dom0 kernel: WARNING: CPU: 11 PID: 1332 at arch/x86/xen/multicalls.c:190 xen_mc_flush+0x21e/0x510
Aug 30 22:59:46 dom0 kernel: Modules linked in: intel_pmc_ssram_telemetry(+) fjes(+) sparse_keymap acpi_pad(-) joydev loop fuse xenfs nfnetlink zram lz4hc_compress lz4_compress dm_thin_pool dm_persistent_data dm_bio_prison dm_crypt xe drm_suballoc_helper drm_gpusvm_helper nouveau mxm_wmi drm_ttm_helper i915 gpu_sched drm_gpuvm drm_exec drm_buddy nvme i2c_algo_bit sdhci_pci ttm ucsi_acpi sdhci_uhs2 nvme_core typec_ucsi spi_pxa2xx_platform nvme_keyring sdhci drm_display_helper typec dw_dmac nvme_auth hid_multitouch xhci_pci cqhci polyval_clmulni ghash_clmulni_intel spi_pxa2xx_core hkdf mmc_core xhci_hcd intel_vsec intel_vpu thunderbolt i2c_hid_acpi cec video i2c_hid wmi pinctrl_meteorlake pinctrl_meteorpoint serio_raw xen_acpi_processor xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn scsi_dh_rdac scsi_dh_emc scsi_dh_alua uinput i2c_dev
Aug 30 22:59:46 dom0 kernel: CPU: 11 UID: 0 PID: 1332 Comm: (udev-worker) Not tainted 6.18.44-1.qubes.fc41.x86_64 #1 PREEMPT(full) 
Aug 30 22:59:46 dom0 kernel: Hardware name: TUXEDO TUXEDO Stellaris 16 Intel Gen7/X6AR5xxY_mLED, BIOS N.1.33A24 07/13/2026
Aug 30 22:59:46 dom0 kernel: RIP: e030:xen_mc_flush+0x21e/0x510
Aug 30 22:59:46 dom0 kernel: Code: 49 8b 7f 20 4d 8b 57 38 4d 8b 47 40 e8 7b 33 21 01 49 89 47 18 48 85 c0 0f 89 cd fe ff ff 8b 95 00 88 4b 83 41 be 01 00 00 00 <0f> 0b 65 8b 0d bd 20 fc 02 44 89 f6 48 c7 c7 50 6e fe 81 e8 9a e1
Aug 30 22:59:46 dom0 kernel: RSP: e02b:ffffc90043e3f4a0 EFLAGS: 00010086
Aug 30 22:59:46 dom0 kernel: RAX: fffffffffffffff0 RBX: 0000000000000000 RCX: ffff88821f0e2000
Aug 30 22:59:46 dom0 kernel: RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff8881a259b010
Aug 30 22:59:46 dom0 kernel: RBP: ffff88821f0e2000 R08: 0000000000000000 R09: ffffc90043863fff
Aug 30 22:59:46 dom0 kernel: R10: 0000000000007ff0 R11: ffffc90043863fff R12: 0000000000000001
Aug 30 22:59:46 dom0 kernel: R13: 8000000000000073 R14: 0000000000000001 R15: ffff8881a259a800
Aug 30 22:59:46 dom0 kernel: FS:  0000704546716380(0000) GS:ffff88821f0e2000(0000) knlGS:0000000000000000
Aug 30 22:59:46 dom0 kernel: CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 30 22:59:46 dom0 kernel: CR2: 0000704545ed8cd3 CR3: 0000000123906000 CR4: 0000000000050660
Aug 30 22:59:46 dom0 kernel: Call Trace:
Aug 30 22:59:46 dom0 kernel:  <TASK>
Aug 30 22:59:46 dom0 kernel:  ? xen_extend_mmu_update+0x1e/0xd0
Aug 30 22:59:46 dom0 kernel:  ? xen_mc_issue+0x20/0x70
Aug 30 22:59:46 dom0 kernel:  xen_leave_lazy_mmu+0x15/0x50
Aug 30 22:59:46 dom0 kernel:  vmap_range_noflush+0x502/0x780
Aug 30 22:59:46 dom0 kernel:  __ioremap_caller+0x26b/0x350
Aug 30 22:59:46 dom0 kernel:  ? pmc_ssram_telemetry_get_pmc+0x12c/0x200 [intel_pmc_ssram_telemetry]
Aug 30 22:59:46 dom0 kernel:  pmc_ssram_telemetry_get_pmc+0x12c/0x200 [intel_pmc_ssram_telemetry]
Aug 30 22:59:46 dom0 kernel:  intel_pmc_ssram_telemetry_probe+0xa7/0xe0 [intel_pmc_ssram_telemetry]
Aug 30 22:59:46 dom0 kernel:  local_pci_probe+0x45/0x90
Aug 30 22:59:46 dom0 kernel:  pci_call_probe+0x5b/0x180
Aug 30 22:59:46 dom0 kernel:  ? _raw_spin_unlock+0xe/0x30
Aug 30 22:59:46 dom0 kernel:  pci_device_probe+0x9b/0x180
Aug 30 22:59:46 dom0 kernel:  really_probe+0xde/0x340
Aug 30 22:59:46 dom0 kernel:  ? pm_runtime_barrier+0x54/0x90
Aug 30 22:59:46 dom0 kernel:  ? __pfx___driver_attach+0x10/0x10
Aug 30 22:59:46 dom0 kernel:  __driver_probe_device+0x84/0x140
Aug 30 22:59:46 dom0 kernel:  driver_probe_device+0x1f/0xa0
Aug 30 22:59:46 dom0 kernel:  __driver_attach+0xba/0x1c0
Aug 30 22:59:46 dom0 kernel:  bus_for_each_dev+0x8e/0xe0
Aug 30 22:59:46 dom0 kernel:  bus_add_driver+0x142/0x220
Aug 30 22:59:46 dom0 kernel:  driver_register+0x72/0xd0
Aug 30 22:59:46 dom0 kernel:  ? __pfx_intel_pmc_ssram_telemetry_driver_init+0x10/0x10 [intel_pmc_ssram_telemetry]
Aug 30 22:59:46 dom0 kernel:  do_one_initcall+0x5a/0x310
Aug 30 22:59:46 dom0 kernel:  do_init_module+0x90/0x250
Aug 30 22:59:46 dom0 kernel:  init_module_from_file+0x88/0xd0
Aug 30 22:59:46 dom0 kernel:  idempotent_init_module+0x114/0x310
Aug 30 22:59:46 dom0 kernel:  __x64_sys_finit_module+0x6d/0xd0
Aug 30 22:59:46 dom0 kernel:  do_syscall_64+0x87/0x7e0
Aug 30 22:59:46 dom0 kernel:  ? ima_file_check+0x70/0xa0
Aug 30 22:59:46 dom0 kernel:  ? mntput_no_expire+0x49/0x290
Aug 30 22:59:46 dom0 kernel:  ? terminate_walk+0x62/0x100
Aug 30 22:59:46 dom0 kernel:  ? path_openat+0x119/0x2a0
Aug 30 22:59:46 dom0 kernel:  ? do_filp_open+0xd7/0x190
Aug 30 22:59:46 dom0 kernel:  ? __seccomp_filter+0x50/0x360
Aug 30 22:59:46 dom0 kernel:  ? syscall_exit_work+0x108/0x140
Aug 30 22:59:46 dom0 kernel:  ? do_syscall_64+0xbe/0x7e0
Aug 30 22:59:46 dom0 kernel:  ? do_syscall_64+0xbe/0x7e0
Aug 30 22:59:46 dom0 kernel:  ? clear_bhb_loop+0x40/0x90
Aug 30 22:59:46 dom0 kernel:  ? clear_bhb_loop+0x40/0x90
Aug 30 22:59:46 dom0 kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
Aug 30 22:59:46 dom0 kernel: RIP: 0033:0x7045469005fd
Aug 30 22:59:46 dom0 kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fb 57 0f 00 f7 d8 64 89 01 48
Aug 30 22:59:46 dom0 kernel: RSP: 002b:00007ffdeb1cfb88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
Aug 30 22:59:46 dom0 kernel: RAX: ffffffffffffffda RBX: 000057d5b8c3ea00 RCX: 00007045469005fd
Aug 30 22:59:46 dom0 kernel: RDX: 0000000000000000 RSI: 00007045466fe3bd RDI: 0000000000000023
Aug 30 22:59:46 dom0 kernel: RBP: 00007ffdeb1cfc40 R08: 0000000000000001 R09: 00007ffdeb1cfbd0
Aug 30 22:59:46 dom0 kernel: R10: 0000000000000040 R11: 0000000000000246 R12: 00007045466fe3bd
Aug 30 22:59:46 dom0 kernel: R13: 0000000000020000 R14: 000057d5b8c06600 R15: 000057d5b8c3ed60
Aug 30 22:59:46 dom0 kernel:  </TASK>
Aug 30 22:59:46 dom0 kernel: ---[ end trace 0000000000000000 ]---
Aug 30 22:59:46 dom0 kernel: 1 of 1 multicall(s) failed: cpu 11
Aug 30 22:59:46 dom0 kernel:   call  1: op=1 arg=[ffff8881a259b010] result=-16
Aug 30 22:59:46 dom0 kernel: BUG: unable to handle page fault for address: ffffc90043863003
Aug 30 22:59:46 dom0 kernel: #PF: supervisor read access in kernel mode
Aug 30 22:59:46 dom0 kernel: #PF: error_code(0x0000) - not-present page

The telemetry driver tries to access an unmapped page, which freaks xen out.

5

Bloged’s Xen-vs-bare-metal read matches what your stacktrace shows. The interesting bit is the xen_mc_flush warning with multicall result -16 right before the page fault on that ffffc900 address. That usually means the telemetry driver is touching MMIO that Xen never mapped into the guest, which is why the same kernel is fine on bare Fedora.

If you need S3 and blacklisting is not acceptable, two practical next steps:

1. Boot with modprobe.blacklist=intel_pmc_ssram_telemetry and check whether intel_pmc_core alone still gives you usable suspend (cat /sys/power/mem_sleep and a short suspend test).

2. File or bump a Xen/Qubes kernel bug with that stacktrace plus lspci -nn -s 00:14.0 and the exact kernel (uname -r). The older pmc_core Xen mmap fix likely needs the same treatment in the new intel_pmc_ssram_telemetry driver.

Meanwhile mem_sleep_default=s2idle can keep the machine usable while that lands, even if battery drain is worse than real S3.