On Friday, February 7, 2020 at 3:15:38 PM UTC-6, Claudia wrote: > > February 7, 2020 8:10 PM, zach...@gmail.com <javascript:> wrote: > > > On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com > wrote: > > > >> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: > >>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:> I have a Thinkpad > T495 with an AMD Ryzen Pro > >>> 3700U and Vega 10 graphics. Everything seems to be > >>>> working besides suspend/resume which is crucial for me since I'm on > the go a lot. I had to build > >>> my > >>>> own Qubes R4.0 ISO to get the installer to work due to it needing a > 5.0+ kernel for the graphics > >>>> driver. I installed `kernel-latest` from qubes-dom0-current testing > but still didn't work. After > >>>> trying every kernel option on the face of this Earth I decided to use > an experimental Qubes R4.1 > >>>> build as some things were pointing to dom0 Fedora 25 being the issue. > On dom0 Fedora 31 it's > >>> still > >>>> an issue with a 5.4 kernel. Has been driving me nuts as I've spent > almost the whole day trying to > >>>> figure the issue out. > >>>> > >>>> When I suspend, it clearly suspends but when I open it back up the > screen is off but the power > >>> LED > >>>> is on. I can hear the fan spin up for a bit but nothing happens. CTRL > + ALT + Backspace does > >>>> nothing. I also tried switching to text mode before suspending with > CTRL + ALT + F2. Nothing... I > >>>> also disabled the compositor in XFCE to give it a try in both R4.0 > and R4.1, no difference. It > >>>> totally seems like an X server or amdgpu issue but I really don't > know what to do. > >>>> > >>>> I don't have any VMs running when I test the suspend and I don't have > a sys-usb VM to take that > >>> out > >>>> of the equation. Any ideas? I'm scratching my head over here and I'm > at a loss on what to try > >>> next. > >>>> > >>> > >>> Did you try the Xen power.c patch? > >>> > >>> It sounds like a Xen panic. Some or all AMD Fam15h processors change > their CPUID feature bits after > >>> resume, which triggers a Xen panic (LEDs and fans on, screen off, > keyboard and power button > >>> unresponsive). There is a patch and instructions towards the end of > this thread: > >>> > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - > It takes some work but it > >>> sounds very likely it will fix your problem. Sys-usb causes other > problems on a lot of Ryzen > >>> machines, so continue to keep it disabled for now. > >>> > >>> It doesn't sound like a graphics problem. Usually X or amdgpu issues > result in the screen's > >>> backlight coming on but displaying a blank screen, and often the > keyboard is responsive just not > >>> the screen. At least in my experience. > >>> > >>> PS: when replying to mailing lists please write your response *below* > the quoted text you're > >>> replying to. > >> > >> Thanks for responding Claudia! I haven't tried that patch but I saw it > in your other thread. I > >> guess my options are pretty exhausted at this point so I'll give it a > try. I've never actually > >> built an RPM outside of qubes-builder. I'm assuming I should just build > the entire Qubes R4.0 > >> (stable) ISO with the edit included. I've never had such a complex > issue before so this is all new > >> to me. > > Not sure what you mean about building an RPM outside qubes-builder. This > is all done within qubes-builder. So if you have any experience at all with > that, then you're already off to a way better start than I was. It wasn't > nearly as bad as I thought it would be either. The GUI script does most of > the work for you. I tried to leave a sufficiently detailed diary of what I > did because I knew it would come in handy later (whether for myself or > others). And, you can always ask the mailing list for help. > > I just built the RPMs. Building the whole ISO apparently takes many hours > and many GB of disk space. And, as with building anything, keep in mind if > something goes wrong mid-build, there's a good chance you'll have to start > over from the beginning. It took me several attempts. Either method should > work the same though, so it's up to you. >
Took me a bit to figure out but I applied the changes to `patch-x86-check-feature-flags-after-resume.patch` and I'm building the whole ISO now. I'm not actually sure how to build the RPM itself, and not the ISO. To be honest I've got like 100 tabs open so maybe I'm missing something... Once the ISO builds and I install it, I assume I just want to add vmm-xen to my yum/dnf excludes so no new vmm-xen package gets installed without the patch. > >> Should we get the Qubes team to include this patch as a fix for AMD? > I'm not sure what the security > >> implications are but I would assume it could introduce an issue where > the Spectre/Meltdown > >> microcode patches would not be applied when resuming? I'm also assuming > the code is functioning as > >> intended, as it panics but what would the real solution be? I wonder if > there's any official fix by > >> Xen in the works rather than commenting out that panic line. Even in > Qubes R4.1 with Xen 4.13 the > >> issue persists. > > I've been thinking about that. I asked the original author if he reported > it to upstream or intended to, but I never heard back from him. I think the > Qubes devs would probably just say it's Xen's responsibility, and I can't > say I disagree. I've been meaning to mention it on xen-devel but haven't > gotten around to it. You're welcome to do so too if you want (if you do, > please CC me). My thought was adding a Xen command line argument to > override this check, e.g. recheck_cpuid_bits=false (default true, of > course), but I have no idea if it would be accepted. > I preemptively submitted this PR to see what the Qubes team thinks. https://github.com/QubesOS/qubes-vmm-xen/pull/70 I agree it probably should be fixed upstream, although I've seen the Qubes team make exceptions and apply their own changes. Upstream would probably take a huge amount of time to get merged and tested. I'm not a developer though so I'm sure you could explain the issue better than I. If you do mention it, CC me as well! I like the CLI argument idea, that's probably a much cleaner way of doing it and defaulting it to true. That way users could disable it if needed due to hardware screw-ups. >> Sorry about the email above yours, Google groups wants to put it above > your quote by default for > >> some reason. I was also exhausted from trying 1000 kernel boot options > lol. > > No worries, trust me you're not the first one. Terrible decision on > google's part. > > > Also... The patch shouldn't really have any security implications > assuming your BIOS has the latest > > microcode patches right? I'm guessing this is only for microcode > packages installed on the OS. > > I have no idea really. I haven't been able to figure out what those > feature bits actually mean, if anything. I get the feeling the original > authors of that code didn't know either. It kind of looks to me like > someone just noticed some bits changing and decided to add a panic just to > be on the safe side. Mainly because that code doesn't actually look for any > specific bits, it just compares the entire set of flags before and after > resume. But I don't know. Use it at your own risk. > > BTW, if the patch works for you, please post the output of `xl dmesg` > showing which bits have changed after resume. I'm curious if it's the same > on all machines. > That sounds like a good explanation to me, was probably just to be on the safe-side. I will report back if it works, probably going to take a while to build since Fedora 25 likes to compile/build with single-threaded GCC lol... -- 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/abe65eb5-1d6b-47c7-a294-f6fb43ed1f58%40googlegroups.com.
