Jun 09 22:08:28 dom0 kernel: audit: type=1106 audit(1781057308.593:748): pid=12203 uid=1000 auid=1000 ses=3 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:08:28 dom0 kernel: audit: type=1104 audit(1781057308.594:749): pid=12203 uid=1000 auid=1000 ses=3 msg=‘op=PAM:setcred grantors=pam_env,pam_fprintd acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:08:29 dom0 kernel: audit: type=1101 audit(1781057309.281:750): pid=12296 uid=1000 auid=1000 ses=3 msg=‘op=PAM:accounting grantors=pam_unix acct=“user” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:08:29 dom0 kernel: audit: type=1123 audit(1781057309.283:751): pid=12296 uid=1000 auid=1000 ses=3 msg=‘cwd=“/home/user” cmd=71756265732D646F6D302D757064617465202D79 exe=“/usr/bin/sudo” terminal=? res=success’
Jun 09 22:08:29 dom0 kernel: audit: type=1110 audit(1781057309.283:752): pid=12296 uid=1000 auid=1000 ses=3 msg=‘op=PAM:setcred grantors=pam_env,pam_fprintd acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:08:29 dom0 kernel: audit: type=1105 audit(1781057309.309:753): pid=12296 uid=1000 auid=1000 ses=3 msg=‘op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:32 dom0 kernel: audit: type=1106 audit(1781057792.281:754): pid=12296 uid=1000 auid=1000 ses=3 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:32 dom0 kernel: audit: type=1104 audit(1781057792.281:755): pid=12296 uid=1000 auid=1000 ses=3 msg=‘op=PAM:setcred grantors=pam_env,pam_fprintd acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: loop11: detected capacity change from 0 to 1541088
Jun 09 22:16:34 dom0 kernel: audit: type=1103 audit(1781057794.384:756): pid=12743 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: audit: type=1105 audit(1781057794.425:757): pid=12743 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: audit: type=1106 audit(1781057794.433:758): pid=12743 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: audit: type=1104 audit(1781057794.433:759): pid=12743 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: audit: type=1103 audit(1781057794.452:760): pid=12777 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:34 dom0 kernel: audit: type=1105 audit(1781057794.460:761): pid=12777 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:35 dom0 kernel: xen-blkback: backend/vbd/15/51712: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:35 dom0 kernel: xen-blkback: backend/vbd/15/51728: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:35 dom0 kernel: xen-blkback: backend/vbd/15/51744: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:35 dom0 kernel: xen-blkback: backend/vbd/15/51760: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:35 dom0 kernel: loop12: detected capacity change from 0 to 1541088
Jun 09 22:16:35 dom0 kernel: audit: type=1103 audit(1781057795.827:762): pid=12901 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:35 dom0 kernel: audit: type=1105 audit(1781057795.837:763): pid=12901 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:36 dom0 kernel: xen-blkback: backend/vbd/16/51712: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:36 dom0 kernel: xen-blkback: backend/vbd/16/51728: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:36 dom0 kernel: xen-blkback: backend/vbd/16/51744: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:36 dom0 kernel: xen-blkback: backend/vbd/16/51760: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:36 dom0 kernel: loop13: detected capacity change from 0 to 1541088
Jun 09 22:16:37 dom0 kernel: xen-blkback: backend/vbd/17/51712: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:37 dom0 kernel: xen-blkback: backend/vbd/17/51728: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:38 dom0 kernel: xen-blkback: backend/vbd/17/51744: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:38 dom0 kernel: xen-blkback: backend/vbd/17/51760: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Jun 09 22:16:42 dom0 kernel: kauditd_printk_skb: 10 callbacks suppressed
Jun 09 22:16:42 dom0 kernel: audit: type=1131 audit(1781057802.422:774): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=user@0 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:42 dom0 kernel: audit: type=1131 audit(1781057802.504:775): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=user-runtime-dir@0 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:43 dom0 kernel: audit: type=1106 audit(1781057803.005:776): pid=12777 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:43 dom0 kernel: audit: type=1104 audit(1781057803.005:777): pid=12777 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:45 dom0 kernel: audit: type=1106 audit(1781057805.794:778): pid=12925 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:45 dom0 kernel: audit: type=1104 audit(1781057805.794:779): pid=12925 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:48 dom0 kernel: audit: type=1106 audit(1781057808.646:780): pid=13134 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:16:48 dom0 kernel: audit: type=1104 audit(1781057808.646:781): pid=13134 uid=0 auid=4294967295 ses=4294967295 msg=‘op=PAM:setcred grantors=pam_rootok acct=“user” exe=“/usr/sbin/runuser” hostname=? addr=? terminal=? res=success’
Jun 09 22:17:41 dom0 kernel: xen-backend console-16-0: xenbus: device forcefully removed from xenstore
Jun 09 22:18:04 dom0 kernel: xen-backend console-17-0: xenbus: device forcefully removed from xenstore
Jun 09 22:18:05 dom0 kernel: xen-backend console-15-0: xenbus: device forcefully removed from xenstore
I’ve seen other people with the exact same laptop/specs hit random freezes too, on both Qubes and CachyOS, so this is starting to look like a laptop/firmware issue rather than just an OS issue
I’ve also tried cachy os before and also had like weird issues on there with this same laptop
My logs showed repeated PCIe AER timeout errors for the Realtek RTS525A card reader (10ec:525a , 0000:2c:00.0 ), plus ASUS firmware/APIC mismatch warnings at boot
bump
It might be you won’t find a solution to your problem here at this time, given no one has chimed in. I did look briefly at the journals you pasted but I wasn’t clear what you’re giving us, like one of the journals has a very big time gap (a bad copy paste job? beginning and end? something else?), and neither of the pastes were contextualized, so it didn’t feel like a good use of my time.
Some feedback for you, when you’re asking strangers for help it’s best for you to do what you can to facilitate that, like do some of your own inspection of the journals first and say what you saw, if anything. And then rather than just paste a raw journal excerpt and click post, it would help your case to say something like “these log lines are from the end of the journal, before or during the freeze”- assuming that’s the case. You get the idea. I’m sorry you’re dealing with a random freeze, that’s very frustrating.
I found the issue for the freezes
The issue was the kernel instead of getting a newer one i switched to the same one i use for my sys-net and now the freezes have stopped does anyone know why this is
the version was 6.12 that stopped the freezes
Nevermind it still randomly freezes the freezes did stop for 4 days and 2 days ago it froze like 5 times yesterday it froze once and today once
As the owner of a laptop from the same company, I recommend doing this, and then using any online instructions to disable the Nvidia GPU.
From experience, I recommend this: GitHub - bayasdev/envycontrol: Easy GPU switching for Nvidia Optimus laptops under Linux · GitHub. It requires installation in dom0, reliably disables the GPU, and after using it, my idle temperature dropped from 86 to 40 degrees Celsius.
I couldn’t find a way to disable the Nvidia GPU without rebuilding the kernel. Various flags hide the GPU from dom0, but it still runs, consumes power, and for some reason gets very hot.
I also recommend disabling CPU boost. This is a one-time operation with some Xen command; ask AI or check the Xen Power Management documentation.
Thanks i will try it
Oh but my laptop isnt getting hot anymore because i blacklisted the gpu in grub
But im still facing random freezes
I can’t say for sure if recompiling the kernel will fix the strange freezes, but it is a reversible procedure that carries no risk to the OS (you can always select the old kernel in GRUB at startup).
However, since no one else seems to have any ideas and the logs aren’t providing useful information, I would give it a try if I were you. The only thing you stand to lose if it fails is a bit of your time.
I can mention that I’m experiencing something vaguely similar. If I enable the GPU, pass it through to a VM, shut down the VM, and then disable the GPU, the entire system freezes completely, and the screen stops updating. It’s hard to tell if it’s responding to input, as the screen image doesn’t change without a hard reboot (holding down the power button).
P.S.:
The asus-armoury driver has been included in the mainline Linux kernel since version 6.19. If the Armoury driver is the only feature you require, installing a custom kernel is no longer necessary
This driver (like asus_wmi) won’t load as a kernel module unless you recompile the kernel with PCIe hotplug enabled.
This might be related and could potentially help. You might also find something useful here: ASUS Linux - ArchWiki
And in other sections of the documentation for ASUS laptops.
Like my entire qubes just randomly hard freezes nothing works all i see is the last frame it was on or if it was in hybernation it just says black if i move my mouse or click on any key
I tried a lot of things
Like blacklisting the gpu in grub
Blacklisting vmd in grub
Used older kernels and newer kernels
Also another person with the exact same laptop as mine also experienced the exact same issues on qubes os so the laptop is the issue
I have used the same external usb with qubes on it on my older laptop and pc and it works completely fine on it its just with this asus laptop from 2025 where it keeps having weird issues
So I’ve tried more things this week and it still keeps randomly freezing.
Here’s everything I’ve done so far, still no luck fixing the freezes or the sleep/suspend crash:
Kernel & WiFi fixes:
- Confirmed I’m on kernel 6.19.14-1.qubes.fc41 in dom0
- Fixed WiFi (Intel BE201, iwlwifi-bz family) by manually adding
iwlwifi-bz-b0-gf-a0-98.ucodeandiwlwifi-bz-b0-gf-a0-100.ucodeto/lib/firmware/in my debian-13-xfce template (Debian 13 stable only ships up to version 96, kernel 6.17+ needs 98/100 minimum)
GRUB changes (GRUB_CMDLINE_LINUX):
i915.enable_dpcd_backlight=1rd.qubes.hide_pci=01:00.0,01:00.1(hiding RTX 5070 from dom0)nouveau.modeset=0rd.driver.blacklist=nouveauintel_idle.max_cstate=1mem_sleep_default=deeppcie_aspm=offmodprobe.blacklist=nouveauxen_privcmd.unrestrictedacpi_osi=Linux(still testing)
GRUB changes (GRUB_CMDLINE_XEN_DEFAULT):
cpufreq=xen:hwp=off(already added, freeze still happens)
Sleep issue:
cat /sys/power/mem_sleepstill showss2idle [deep]— meaning s2idle stays active even withmem_sleep_default=deepset. The BIOS seems to override it regardless of the kernel parameter.- Laptop still auto-reboots ~2-3 minutes after waking up from sleep mode.
Freeze issue:
- Freezes happen randomly, sometimes with a black screen, no consistent trigger
cpufreq=xen:hwp=offdid not resolve it- Checked
journalctl -b -1 -p err..emergafter a crash — no logs at all from the crash itself, meaning it’s dying before Linux can write anything (looks like a Xen-level or hardware-level crash, not a kernel panic) - Found boot-time errors that may or may not be related:
- Flood of
[Firmware Bug]: CPU X: APIC id mismatcherrors (known Arrow Lake BIOS bug) intel_vpu: Failed to request firmware: -2(NPU firmware missing)i915: GT1: GSC proxy component didn't bind within the expected timeout
- Flood of
Hardware:
- ASUS ROG Zephyrus G16 2025, model GU605CP
- Intel Core Ultra 9 285H (Arrow Lake-H), RTX 5070, Intel BE201 Wi-Fi 7
For this one:
It is fairly sure it is not a true bug.
For the main problem, do you have 2 or more RAM sticks? You could try taking one out, to eliminate RAM fault.
Its a laptop and the ram is solderd
BIOS:
Running BIOS version GU605CP.307 (dated 11/20/2025) on the ASUS ROG Zephyrus G16 (GU605CP). This is the latest available version, so this isn’t an outdated-BIOS issue on my end.
Current GRUB / kernel boot parameters:
text
root=/dev/mapper/qubes_dom0-root ro
rd.luks.uuid=luks-21da78e5-eeec-45ff-96c4-4f99bd3a57e0
rd.lvm.lv=qubes_dom0/root
rd.lvm.lv=qubes_dom0/swap
plymouth.ignore-serial-consoles
rhgb quiet
i915.enable_psr=0
rd.qubes.hide_pci=01:00.0,01:00.1
nouveau.modeset=0
rd.driver.blacklist=nouveau
modprobe.blacklist=nouveau
intel_idle.max_cstate=1
mem_sleep_default=deep
acpi_osi=Linux
pcie_aspm=off
xen_privcmd.unrestricted
A few of these are already mitigation attempts, in case anyone hasn’t tried them yet:
-
rd.qubes.hide_pci=01:00.0,01:00.1— this hides the discrete Nvidia RTX GPU’s PCI function from dom0 entirely at boot. -
nouveau.modeset=0+ blacklisting nouveau (bothrd.driver.blacklistandmodprobe.blacklist) — makes sure the open-source Nvidia driver never touches the GPU at all. -
intel_idle.max_cstate=1— limits how deep the CPU can idle, sometimes used to work around freeze/wake bugs tied to deep C-states on newer Intel chips. -
mem_sleep_default=deep— forces S3-style deep sleep instead of s2idle for suspend. -
pcie_aspm=off— disables PCIe Active State Power Management, which is a common culprit in random freezes/wakes on newer laptops with iGPU+dGPU switching. -
i915.enable_psr=0— disables Panel Self Refresh on the Intel display, another common freeze-related workaround.
So to be clear: I already have the GPU hidden, nouveau blocked, ASPM off, PSR off, and C-states capped, and I’m still getting the hard freezes. That rules out a decent chunk of the “usual suspect” boot-flag fixes for people following this thread — if you’ve got all of these set too and still freezing, it’s probably not a simple ASPM/C-state/PSR issue.
Kernel:
6.19.14-1.qubes.fc41.x86_64 for dom 0 and app vms
Also my laptop reboots randomly after 2-3 minutes after waking up from sleep mode
Has anyone else ever had random freezes everyday?
It seems to be related to suspend - or at least, there may be a connection.
Do you have any related settings in the BIOS/Setup?
I notice that modern systems have S0ix suspend, sometimes with no possibility to switch to S3 or other. The forum has some posts of folk reporting success with the related qvm-feature.
Could that help?
Good thought, but doesn’t look suspend-related for me. I already have mem_sleep_default=deep set, which forces S3-style sleep instead of S0ix, and I still got the freezes. Also, mine hit mid-session while actively awake and in use, not around suspend/resume at all. ASUS doesn’t give a BIOS toggle for S3 vs S0ix on this model either, it’s locked to Modern Standby, so the kernel flag is the only lever here.
You are focusing on the Linux kernel and it’s parameters…
However in case of Qubes OS, Xen is running directly on your hardware, and that might cause the freeze.
If you can try any modern Linux distro on the same hardware, you will see if the hard-freezes (or any other hardware related issue) are still there or not.
This is still not a ‘silver bullet’, but at least telling you if it is Qubes related or not.
Others seems to have issues as well:
And the mere existence of these tools mithg be also related: