On Tue, May 10, 2022 at 09:26:48PM +0100, Laurence Tratt wrote: > On Tue, May 10, 2022 at 09:08:04PM +1000, Jonathan Gray wrote: > > Hello Jonathan, > > >>> I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. > >>> Over that time nearly all of the GPU related bugs have disappeared > >>> (thanks Jonathan et al.!), except for the fact that I don't seem to be > >>> able to reliably suspend/resume from X. > >> I thought it might be worth noting that, unfortunately, despite amdgpu and > >> mesa updates this machine still can't reliably suspend or resume once X is > >> doing something. [From the non-X terminal, suspend/resume works fine.] > >> > >> Since I guess this machine is now fairly standard hardware, I wonder if > >> there's some obvious X or BIOS setting that I should be tweaking, but > >> nothing I've tried seems to help so far! > > I can't think of anything besides the tpm bios settings on some intel based > > laptops a while ago. > > > > "AMDIF030" at acpi0 not configured is a gpio device without a driver. > > Perhaps that state needs to be restored? > > Though that appears on a x470 board I can resume and unhibernate on with a > > vega10 card. > > Maybe! Would that device have some sort of interaction with X one way or > another? Because it seems that I can reliably suspend/resume if xenodm is on > the login page, but after I've logged in via xenodm, suspend rarely works > and, if it does, resume almost certainly doesn't. > > As that suggest, I haven't got a clue where to start with this! > > > Laurie >
Whether or not xenodm is at the login page or not should have no bearing on zzz/ZZZ. Are you running something at login or after login that interacts with hardware in some way that would put things in a weird state? If you can't suspend, it probably means either a device is stuck in either the quiescing or suspending mode and not returning control to the kernel to finish the zzz. I'd put in some code to unwind the zzz after all the devices are quiesced, then see if 'zzz' immediately "resumes" from the failure. If that works, it means the problem is later in the sequence; try the same thing for right after the suspend phase. If that works, then the problem is in your EC or BIOS (or aml). Note that our unwind-from-failed-zzz is not perfect, but you may get lucky. In a nutshell, you have all the code in front of you to diagnose where this fails. -ml
