On Monday, October 7, 2019 at 3:42:38 PM UTC+2, Claudia wrote: > > Tomáš Vondra: > > > > > > On Saturday, October 5, 2019 at 7:45:40 PM UTC+2, Tomáš Vondra wrote: > >> > >> On Friday, October 4, 2019 at 4:36:57 PM UTC+2, Claudia wrote: > >> > > ... > >> > >> > >>> There is a pre-release 4.1 iso available. > >>> https://openqa.qubes-os.org/tests/3021 > >>> < > https://www.google.com/url?q=https%3A%2F%2Fopenqa.qubes-os.org%2Ftests%2F3021&sa=D&sntz=1&usg=AFQjCNEtwV-7EB_Hj9-89w3F8kL7XBW3pA> > > > >>> - this is a kind of old link so > >>> newer builds may be available. I could not get it to install on my > >>> machine so I couldn't test suspend on it, but it might work for you. > >>> > >>> > >> Thanks for the link. I gave it a try and there seems to be some > >> improvement compared - the installer now works out of the box, without > >> having to tweak it like I had to with Qubes 4.0. Unfortunately, the > >> suspend/resume issue is still there, although maybe it actually gets to > >> sleep this time (but still does not wake up). > >> > >> I've tried looking for a newer build (the one you posted is from July, > so > >> a couple of months ol), but I haven't found anything. I've been trying > to > >> build ISO locally over the past two weeks, but I keep running into > issues > >> so I haven't been successful in that. > >> > >> > > > > OK, I've noticed there actually is a link to the latest job for that > > scenario, leading to https://openqa.qubes-os.org/tests/3737 (which is > > 2019/08/22 instead of 2019/07/01). Unfortunately the suspend behavior is > > the same as for the older build :-( > > > > regards > > > > > > > > You mean out of the box? Or when dom0 is brought fully up to date? Odds > are slim, but updating might fix the problem. Also enabling > testing/unstable repos might help. > > After updating dom0. Unfortunately I'm unable to switch to testing repos because dnf started complaining about a missing config file for some reason, and I haven't managed to fix that (yet).
> As far as building your own iso, I'm afraid I don't know anything about > that, but there are plenty of people on this list who could help if you > start a thread about the specific problems you're having. > > Yeah, I plan to try again and I'll start a new thread here (or maybe on qubes-devel, that seems like a better match). > In general, debugging suspend/resume is quite difficult unless you're a > kernel developer with a serial console. However there are a couple of > things you can do that might get you a step further. > > First, it's helpful to know if the machine is actually going into > suspend. Open a few terminals and run `sha256sum /dev/urandom` and wait > for the fans to start running. If you hear them stop, you know it > suspended. If, on resume, you hear them start up again, then it could be > that the machine is partially resuming but just the screen is not coming > back on (possibly indicative of a GPU or WiFi driver problem). Playing a > repeating sound probably has the same effect. You can also hit caps lock > and num lock after resume and see if the lights change. > > Try shutting down all VMs before suspending. I think the command is > `qvm-shutdown --all --force --wait` or something like that. Make sure > they're all stopped (e.g., `qvm-ls`). This can tell you if something > with PCI passthru is causing a problem, such as (most likely) the NetVM > or UsbVM (wifi card, wifi driver, usb controller). > > Another idea, try disabling VT-x and VT-d in BIOS, then boot Qubes and > try suspend. This might tell you if it's a Xen problem, or a firmware > bug related to VT-x, for example. > > If the option is present, try disabling the onboard WiFi card in BIOS. > It's worth trying this for any other hardware too (dGPU, etc). > > Thanks, I'll do more experiments like this with it. > Try upgrading your machine's firmware. On dell you can do this via > fwupd, Freedos, or using the boot-menu option to upgrade from USB drive. > On my Dell, option 3 was simply broken, so I had to do it from Freedos. > > That was the first thing I did after getting the laptop. I've managed to upgrade the BIOS only to 2.4.0, though. There is 2.5.0 but upgrading that from USB did not work. Unfortunately, fwupd does not seem to be supported for this laptop (at least that's my undestanding). > Try installing Fedora with Xen (the basis of Qubes) and see if it > resumes from there. > > Hmmm? Not sure what you mean by Fedora with Xen? > There are also tons of techniques for debugging suspend on generic > Linux. You can play with acpi_osi=, mem_sleep_default=, `dmesg > > before.txt ; pm-suspend ; dmesg > after.txt`, the list goes on and on. > Here's a nice article to get you started: > > https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues > > > If you want to read my (thus-far unresolved) experience with suspend in > painstaking detail, check out the rest of the thread starting with this > message: > https://www.mail-archive.com/qubes-users@googlegroups.com/msg29755.html > > That's all I can think of at the moment, but hopefully enough to get you > started. > > Thanks for the links, I'll see how far I get based on that. / Tomas -- 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/4a715861-7f7a-417d-a44f-c37a26d4ae01%40googlegroups.com.
