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 -- 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/6a969942-0185-378b-8534-2c3d8cd85966%40guardianproject.info.
