<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Crashes / Resets From AMDGPU / Radeon VII" href="https://bugs.freedesktop.org/show_bug.cgi?id=110674#c79">Comment # 79</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Crashes / Resets From AMDGPU / Radeon VII" href="https://bugs.freedesktop.org/show_bug.cgi?id=110674">bug 110674</a> from <a class="email" href="mailto:reddestdream@gmail.com" title="ReddestDream <reddestdream@gmail.com>"> ReddestDream</a> <pre>>I tried something like that before but a huge portion of the commits in that range won't build kernels that can boot (at least on my system). It's interesting that you found d1a3e239a6016f2bb42a91696056e223982e8538 to improve the issue: <a href="https://github.com/torvalds/linux/commit/d1a3e239a6016f2bb42a91696056e223982e8538#diff-0bc07842bc28283d64ffa6dd2ed716de">https://github.com/torvalds/linux/commit/d1a3e239a6016f2bb42a91696056e223982e8538#diff-0bc07842bc28283d64ffa6dd2ed716de</a> >From Tom B.'s and my review of the code, it seems very likely that somehow a failure to set a hard minimum properly is at the heart of the issue. >This brings me to the second thing: When looking through the commits, I noticed that there were multiple commits that claim to prevent or reduce crashing in high-resolution situations (one references 5k displays, another references 3+ 4k displays). Yeah. I have 2 4K displays as well. But I don't think it should really be straining the card. These commits are probably overzealous for Radeon VII. Rather it could be that at least part of the issue, especially the excessive power draw at idle, is just due to these commits artificially setting minimums very high. In fact, that could be why it's stable at all with just one monitor, since the code to set the minimums up is only being triggered when there are more monitors connected. I'd suspect a boottime configuration issue too, but others have reported instability even when the monitors are hotplugged later on. So, it seems like maybe the monitor detect might at least partially be okay, but the follow-through with raising the clock minimums is broken. I suspect the issue is in the code calculating the minimum to set, so the driver gets stuck trying to send incomplete/incorrect values to the card. <a href="https://bbs.archlinux.org/viewtopic.php?id=247733">https://bbs.archlinux.org/viewtopic.php?id=247733</a> It does make me wonder if it's worth testing like 2 simple 1080p 60 Hz displays. Maybe that wouldn't trigger this issue. Not that that would really be of use to me. But it might help distinguish between just monitor detect generally being broken and "high monitor load" being broken . . .</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>