On Tuesday, January 14, 2020 at 7:58:11 AM UTC-3, Abel Luck wrote: > > Abel Luck: > > 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). > > > > >> Just some general tips: try kernel-latest, and Qubes R4.1, if you > haven't > >> yet. > > > Some interesting news, TL;DR is that I got suspend/resume working! > Here's how: > > > I updated dom0 to kernel-latest, booted again and with all vms off > tested suspend with this script: > > ``` > #!/bin/sh > > sync > echo 1 > /sys/power/pm_trace > echo mem > /sys/power/state > ``` > > Resume worked. However as soon as I turned on sys-usb it failed to > resume again, with the monitor staying off but the keyboard lights > turning on. > > At this point I went into my bios and disabled all the devices I could: > wlan adapter, ethernet adapter, graphics, etc. > > Throughout this point I was constantly checking for the "hash matches" > devices in dmesg and looking at /sys/power/pm_trace_dev_match. Also I > had edited qubes-pciback.sh as described by Claudia. There was never a > clear smoking gun that revealed some particular device, and the values > seemed to change with every reboot or configuration. However at one > point I noticed 'drm' in pm_trace_dev_match, and this would prove > useful later. > > My motherboard has integrated intel graphics (igfx) but also a PCIe > nvidia card. Eventually I happened upon the bios configuration where I > enabled integrated graphics (I had no option to disable the nvidias card > aside from physically removing it). > > Booting into Qubes using the igfx output, I noticed 'drm' in the > pm_trace_dev_match, which I know has something to do with the nouveau > driver. So I disabled as described at > https://www.qubes-os.org/doc/nvidia-troubleshooting/#disabling-nouveau. > > Then resume worked! > > I could have left it there and relied on igfx alone, but I hadn't had > any problems with nouveau, and for various reasons want to use it rather > than igfx. So on a hunch I tried the opposite process. I disabled igfx > in the bios and then added iommu=no-igfx to the GRUB_CMDLINE_LINUX (not > the XEN line) and resume works fine. > > I'm a little confused as to why iommu=no-igfx is necessary since the > bios disabled the igfx card, but whatever, it's working. > > To cleanup I reverted the change in qubes-pciback.sh, removed the > nouveau changes and added the no-igfx param in grub config. > > I should add that at some point I switched from 'echo mem > > /sys/power/state' to 'systemctl suspend' in my test script because the > former would actually resume successfully in more cases, while the > latter never would (until I landed on the gpu solution). > > In summary, it appears suspend/resume Qubes may have some problem when > multiple graphics adapters are present. This hardware suspends/resumes > fine in normal Debian. I observed that blocking one of the adapters and > forcing just a particular one seems to allow suspend/resume to operate > as expected. > > ~abel >
Thank you for all your work Abel. I'm gonna read it carefully and try to apply to my Qubes to find out the problems! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a6312209-8ff9-4674-84be-8e664c318b57%40googlegroups.com.
