2019. április 1., hétfő 23:21:07 UTC időpontban awokd a következőt írta:
> Trying to debug this; not something I use often but would be nice to 
> figure it out. Under Linux Mint 19.1 (no noises please, it was 
> convenient for troubleshooting), suspend "just works"- I close the lid, 
> power light starts blinking off & on, opening lid resumes normally. 
> Under Qubes 4.0.1, closing the lid acts like above, but resume hangs on 
> a black screen and the CPU fan slowly spinning up to full speed. Holding 
> down power button isn't enough to recover- although it will power off, 
> when I power back on it's still stuck the same way. I have to pull the 
> battery and power cable to get it to boot. I've tried:
> - shutting down sys-net and sys-usb prior to suspend
> - shutting down just sys-usb (since only those devices have no-strict-reset)
> - adding mem_sleep_default=deep to kernel boot options
> - adding mem_sleep_default=shallow to kernel boot options [resulted in 
> only screen going to sleep but not coming back]
> - adding acpi.ec_no_wakeup=1 to kernel boot options
> Dmesg says "ACPI: (supports S0 S1 S3 S5)" and /sys/power/mem_sleep says 
> "s2idle shallow [deep]". The last log lines before it enters suspend are:
> dom0 systemd[1]: Starting Suspend...
> dom0 systemd-sleep[3586]: Suspending system...
> dom0 kernel: PM: suspend entry (deep)
> Then nothing until I force a reset.
> Any suggestions for a more intelligent way to troubleshoot? Logs or 
> settings I can look at somewhere in Mint that would give me a hint how 
> it's managing to successfully resume?

This issue is due to a xen patch ("Fix resume, when using microcode upgrade"), 
that has been included when releases changed from xen-4.8.3-4 to xen-4.8.3-5. 
This patch checks the availability of previous CPU features (..Spectre) during 
resume, and results in a xen panic on G505s - IMHO due to the static nature how 
the most recent (0x600111f) AMD microcodes need to be compiled in Corebooted 
It is no use to revert the whole patch, because it'll break the other xen 
patches introduced since. But you can:

diff -ur a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c 2019-03-31
+++ b/xen/arch/x86/acpi/power.c 2019-03-31
@@ -256,9 +256,9 @@
-    if ( !recheck_cpu_features(0) )
+/*    if ( !recheck_cpu_features(0) )
         panic("Missing previously available feature(s).");
     /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
     ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);

have this workaround, which solves the issue until someone provides a working 
solution on CB'd systems with AMD Fam15h. (..and also assesses the possible 
security impacts...) 
Of course you'll need to recompile git:qubes-vmm-xen, but that is 
There could be some strange kernel messages in dom0 after resume, and you might 
have issues in sys-net devices waking up, but this mostly works fine (with 
kernel 4.14.103 --> kernels 4.19-xx still have issues with the radeon module)

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to