January 9, 2020 1:55 AM, "Guerlan" <worms....@gmail.com> wrote:
> First of all, here's the HCL for my Razer Blade Stealth 2016 4K touchscreen > 16gb RAM 512gb SSD: > https://groups.google.com/forum/#!searchin/qubes-users/razer$20blade|sort:date/qubes-users/PalZ-1inx > A/D3mQ4OI3CAAJ > > When I close the lid and open again, keyboard wont ligth up, screen wont turn > on (it's LED so I can > see a brigth black when it turns on), and hitting keyboard or touchpad does > nothing. I have to > reboot. I don't know, however, if keyboard not ligthing when I open the lid > is because sys-usb, > which contains the keyboard, is not waken. Every other aspect of the laptop > seems to be working > perfectly. When you're testing, make sure there are no VMs set to start on boot, especially not sys-net and sys-usb, and make sure rd.qubes.hide_all_usb is not set. You can try to get that stuff working later on. Does pressing caps lock or num lock turn on/off their lights on the keyboard? Does ctrl-alt-delete, or Alt-SysRq-B (you have to enable it first) cause it to reboot? If you suspend with sound playing, can you hear it when you try to resume? > I followed Ubuntu's guide on kernel suspend bugs: > https://wiki.ubuntu.com/DebuggingKernelSuspend > > Then, following what they suggest > > `sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"` > > and find the lines that says hash matches in dmesg rigth after reboot (what > does that mean?) > > Well, I found two: > > ``` > [ 3.583591] ima: Allocated hash algorithm: sha1 > [ 3.593050] input: AT Raw Set 2 keyboard as > /devices/platform/i8042/serio0/input/input4 > [ 3.638808] Magic number: 0:929:176 > [ 3.638867] acpi device:39: hash matches > [ 3.638893] acpi device:0c: hash matches > [ 3.639073] rtc_cmos 00:01: setting system clock to 2016-01-01 12:09:51 UTC > (1451650191) > ``` > > 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. > Then I asked for help on a forum and they found this problematic line on my > dmesg: > > `[ 2.543596] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM` > > seems like ASPM is disabled on my Qubes. I don't know why. Should this be > considered a bug? Is > there anything I can do to get it working? This looks promising. > > It's worth noting that on Ubuntu 18, 19, Fedora 30, Linux Mint, etc, all > these systems work like a > charm with the sleep process. I can close the lid and open and it works. So > the problem seems to be > **related to Qubes**. I even tried qubes most recent dom0 kernel, based on > 5.x linux kernel, but > the problem persists. There's a pretty big difference between Fedora and Qubes. R4.0 is based on Fedora 25, not 30. Also have you tried suspend on any of those OSes with Xen installed and running? Or, have you tried booting Qubes without Xen? (Here's how to boot Qubes 4.0 without Xen: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31138.html - however it may be easier for you to install Qubes 4.1 on a removable drive to test because it comes with Grub already, and you don't have to risk breaking your main installation. Also 4.1 comes with a newer Xen version which might help.) > 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. > `kernel=vmlinuz-4.14.74-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root > rd.luks.uuid=luks-39fc83eb-9829-43b7-86e8-08068bd81087 > rd.lvm.lv=qubes_dom0/root > rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 pcie_aspm=force rhgb quiet > plymouth.ignore-serial-consoles` > > but it didn't help. Didn't help as in didn't make the message go away? Or just didn't fix the suspend issue? > I pratically need to run Qubes on this notebook because any Linux > distribution with any kernel will > have a problem that corrupts my SSD many times a day. No one could solve it, > and on Qubes it never > happens. I tried Qubes just to see if it'd solve and it does! I'm loving it, > not going back even on > other notebooks. However, closing the lid/putting the system to sleep is > essential for a notebook. That's really strange. > ``` > > [lz@dom0 ~]$ cat /sys/power/mem_sleep > s2idle [deep] > > ``` > > as you see, the suspend default is deep mode. > > I tried s2idle by doing `echo freeze > /sys/power/state` and the screen turns > off but they keyboard > keeps with lights on. Pressing buttons does nothing. Pressing touchpad, > nothing. Pressing power > rapidly, nothing. Had to reboot by long pressing power. I thougth s2idle > should always work since > it's software based. I don't have much if any experience with s2idle, but I would think too it would be the most reliable. However, s2idle may power off the VGA controller or GPU or something like that, and if so it could cause a graphics issue just like deep sleep. Does screen poweroff work for you? See: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31504.html > Here's my journalctl of the moment when I go to suspend by closing the lid > (that is, suspending in > deep mode): > ... > > 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. 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" That's all I can think of right now. -- 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/66a83976d56890c338df5e17343ac759%40disroot.org.
