On Saturday, January 11, 2020 at 4:37:17 PM UTC-3, Claudia wrote: > > January 9, 2020 1:55 AM, "Guerlan" <worm...@gmail.com <javascript:>> > 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. >
Hi Claudia, I'm gonna test everything you told, and I'm very thankful for all the help you give here. It's just going to take some days because I sometimes can't pause my workflow to tweak my Qubes. About the NVME problem, I opened a new thread: https://groups.google.com/forum/#!topic/qubes-users/ZVx3tDQ002E If you know anything that can help, please give me some advice. I could finally understand why this bug happens and then I could help people that also suffer from this problem -- 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/6af5c324-b8ad-4b52-adfa-9fe929dd306e%40googlegroups.com.
