Hi there, I'm debugging similar resume issues, though on different hardware. Hopefully you don't mind if we share tips in this thread.
> > I couldn't find anything related to those acpi devices. I thougth first > that there was a driver for > > them, so I should just rmmod those drivers before sleep and insmod when > wakeup, but couldn't find > > anything. There's this issue > https://ubuntuforums.org/archive/index.php/t-2393029.html which have > > those exact hash matches, but no answer. > > I don't know a lot about pm_trace, but it seems like there might be a > problem decoding the hash. > Normally it should show you a PCI address, /sys device name, driver name, > or something more > specific (see example in link below). > > According to s2ram kernel documentation: > > If no device matches the hash (or any matches appear to be false > positives), the culprit may be a > device from a loadable kernel module that is not loaded until after the > hash is checked. You can > check the hash against the current devices again after more modules are > loaded using sysfs: > > cat /sys/power/pm_trace_dev_match > > https://www.kernel.org/doc/html/latest/power/s2ram.html#using-trace-resume > > However, in qubes we may also have the opposite problem. Qubes takes over > your network cards and > sometimes USB controllers in early userspace, so the drivers are not > available anytime. To disable > this behavior for USB controllers, remove rd.qubes.hide_all_usb from the > kernel cmdline. For > network cards it's a little more complicated. > > You can try modifying the qubes initramfs hook. First, make sure there are > no VMs configured to > start automatically at boot. Move > /usr/lib/dracut/modules.d/90qubes-pciback/ to your home > directory, or open the qubes-pciback.sh file and comment out the last 9 or > so lines (from "for dev > in $HIDEPCI"). Rebuild the initramfs. Then, do the pm_trace again as you > did before. Then, try > pm_trace_dev_match as described in the link above. > > It might give you better information about the problem device, or it might > just give you the same > info as before, but it's something to try. > > If it doesn't work, don't forget to put that file back how it was, and > rebuild initramfs again. > Thanks for this tip. Using this method I was able to get a "hash matches" line in my dmesg whereas before I didn't get one. I am also debugging a suspend resume issue but with a Asus z390 I Aorus Pro Wifi motherboard on a desktop (and an nvidia gpu unfortunately). Some interesting facts: 1) the pci device that matched was "INT34B9:00". I can't really find much info about what this device is, it doesn't correspond to anything under lspci. /sys/bus/acpi/devices/INT34B9:00/uid contains the value "SerialIoUart1" 2) suspend and resume works when I execute "echo mem > /sys/power/state". However when I execute the suspend from xfce or run systemctl suspend, the resume fails (with a black screen but the keyboard lights up). > > I also tried `pcie_aspm=force` on `/boot/efi/EFI/qubes/xen.cfg` (is this > where I put kernel > > parameters?) like this: > > Yes on R4.0 you use xen.cfg. On other releases, you use /etc/default/grub. > Unfortunately I don't > know anything about ASPM so you probably know more than I do. > I also don't know much about ASPM, but I noticed my bios had a section for "Active State Power Management" which was disabled, I enabled it (and the sub-options that appeared) but still haven't had luck. > If anyone has other debug ideas, I'm very thankful!!!!!!!!!!!!! > > Just some general tips: try kernel-latest, and Qubes R4.1, if you haven't > yet. > I'm still on 4.0, how does one try 4.1 without a full re-install? > Also make sure your > firmware is up to date. If your machine has a dGPU, disable it in BIOS. > > It doesn't sound like the CPUID Xen panic I had on my machine, but you > could try the Xen patch > anyway, if nothing else works. In my case, only the fan came back on, but > not the screen backlight > or anything else. > > I also had to pin dom0 to CPU 0 to fix a different problem (my SATA > controller was broken after > resume). Add the following to your Xen cmdline ("options=", not > "kernel="!): "dom0_max_vcpus=1 > dom0_vcpus_pin" > > Will give these a try. I have both iwlifi and nouveau, which are definitely top suspects however they haven't given me any issues and so far no evidence points to them being responsible. ~abel -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/47fbbab7-4fff-41fd-b5ea-21ca1ede668b%40googlegroups.com.
