Linux 5.9 Gets More Fixes For AMD RDNA2 GPUs, Promotes Navi 12

[muncrief]

This reads like very productive debugging, patches were found to solve the issue.. And then this bug report was hijacked by lots of people with some seemingly similar issue.

The resume issue has been going on for a very long time, and jumps around from configuration to configuration, with patches working for some and not others.

If the maintainers of the bug believe a new bug report should be started it is their responsibility to say so, and that have not.

[polarathene]

Haha, good one. I'm all Intel in my surface pro 4. Suspend/resume? Well... There are hacks.

I had similar suspend/resume issue with my 2019Q4 laptop model I got (Intel CometLake). Although that's apparently been fixed with firmware update now, I just have to re-install windows to apply it sometime to verify.

For Surface tablets, I recall when investigating my issue that they're designed for Windows feature that differs from typical S3, I forget the technical names, but basically they wanted the tablet to suspend but still keep some parts awake in a lower power state such as wifi. We have something like that in linux/BIOS iirc, it's a different power state to S3, something about suspending to idle, where there's about 3 different levels and on Linux it seemed common not to be able to get to the deepest sleep state without problems on many devices.

Lenovo I think also was guilty of this with some of their laptops, but linux community was vocal enough that they provided a BIOS update to switch to S3 instead which resolved problems the alternative was causing.

I recall with my laptop that I could suspend and resume once from a boot, a 2nd time without a reboot would just panic and fail to power on the display or something. I could use the suspend 2 idle instead, but due to this laptop surprisingly having 2011-2012 display tech to cut costs, it couldn't enter the deeper power state and thus wasn't very power efficient for battery life (even if the display is powered off, since it relies on the Intel iGPU and couldn't do something to permit that entering a lower power state, this also affected other parts such as the CPU IIRC from entering deeper idle/sleep levels).

A possible fix I was considering was what Surface has online with editing the DSTS tables(something like that, BIOS data that affects the suspend/resume logic/capabilities IIRC). Though that probably wouldn't have worked.

---

So uhh yeah, agree that Intel can be just as bad at times :P

[Paradigm Shifter]

Before adding all this new stuff they should have fixed the problem with AMDGPU causing resume failures on a plethora of motherboards, CPUs, and GPUs.

It started around kernel 5.5, and persists all the way to 5.9-rc6.

Really, at this point it's getting crazy.

It's really not only AMD that fails quite hard at this. All the way from 4.18 to 5.6, I suffered through the Iris Pro iGPU in my NUC (and the older Intel iGPU in a Yoga 2 Pro) having regular soft locks and bus resets. Some kernels it was worse (every few minutes) some it was better (once or twice an hour). Some kernels varied from release to release (e.g.: 5.3.0-something would be OK, 5.3.0-something+1 would be absolutely broken, 5.3.0-something+2 would sort-of fix it... it got so bad I went back to 4.15 because that was always working. I'm now running 5.7 on those boxes and have had no further issues (for now?)...

...

As for suspend/resume, I've had so many issues with that on both AMD and Intel over the years (Intel usually due to overclocking, although I never bother any more) that I never use it. Fortunately, my boxes boot fast when I've turned them off, and 99% of the time they are busy anyway so won't (shouldn't) be suspending.

[geearf]

The resume issue has been going on for a very long time, and jumps around from configuration to configuration, with patches working for some and not others.

If the maintainers of the bug believe a new bug should be started it is their responsibility to say so, and that have not.

But Alex did tell you to create a different report.

[Apoll]

because that requires some brain work, while buying intel doesn't

muahahaha good one.

[aufkrawall]

Seems clueless users like to prematurely blame AMD for every issue their systems show. Perhaps Linux is not the right OS for them, which they of course refuse to accept...

[muncrief]

But Alex did tell you to create a different report.

I just checked the bug report again and don't see any message from anyone asking me to file a new bug report geearf . Can you please let me know where you're seeing this message? Thank you.

[geearf]

I just checked the bug report again and don't see any message from anyone asking me to file a new bug report geearf . Can you please let me know where you're seeing this message? Thank you.

Maybe I'm misunderstanding then, but I was referring to this: https://bugzilla.kernel.org/show_bug.cgi?id=204241#c49

[muncrief]

Maybe I'm misunderstanding then, but I was referring to this: https://bugzilla.kernel.org/show_bug.cgi?id=204241#c49

Oh, I see the problem, and it's a perfectly reasonable misunderstanding. The entry you reference is in the correct bug report, but it was from back in December. Alex did request that I file a different report, and that bug was subsequently fixed. And by the way that's when I had my old R9 390.

I've subsequently purchased two RX 580s (I use one for my Windows 10 VM GPU passthrough), and the problem is different. My latest entry is here:

https://bugzilla.kernel.org/show_bug.cgi?id=204241#c68

As I said earlier the resume problem has been going on a very long time, and there are so many different bug reports it's difficult to identify the appropriate place to file. But hopefully I did it right this time!

However I always follow bug threads I'm actively engaged in, and if I screwed up again I'll be sure to file a different report if requested.

[agd5f]

bug 204241 is a mess. The originally reported issue was fixed long ago. I would have closed it long ago, but since kernel bugzilla tickets can only be closed by the reporter or a admin, they tend to stay open forever because most reporters forget to close them.