February 7, 2020 8:10 PM, zachm1...@gmail.com 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. >> 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. >> 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. -- 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/785bc4ede2f008f2a13e8e2bc7c26b11%40disroot.org.
