| Bug ID | 103277 |
|---|---|
| Summary | [bisected] Systems hangs on resume from S3 sleep due to "= ;Match actual state during S3 resume" commit |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | blocker |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | jb5sgc1n.nya@20mm.eu |
After I updated my kernel to https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-staging-drm= -next as of today (latest commit at this time:=20=20=20=20 1c630e83443a0f271c192ecfa0d94023661a0000) I noticed that my computer would = no longer wake up from S3 sleep - power LED goes on, but apart from that no display and no reaction to any input (other than Num-Lock still switchable). The difference to the ~2 weeks older kernel was 100% reproducable by just doing: - boot to console (no start of X11 required) and login as root - echo "mem" >/sys/power/state - wait till power LED blinks - press some key to wake up the system - observe no display output and no reaction to anything GPU is a RX 460, CPU a Ryzen R7 1800X, board Asus X370 Pro, connected is on= e 4k display via HDMI 2.0. I bisected the git commits, and the one that causes the bug is: > 7ae4acd21e9e264afb079e23d43bcf2238c7dbea > drm/amd/display: Match actual state during S3 resume. After this, I went back to the current HEAD of amd-staging-drm-next and (manually) reverted only commit 7ae4acd21e9e264afb079e23d43bcf2238c7dbea, a= nd this indeed results in a kernel that works fine with regards to resuming fr= om S3 sleep. There are no noteworthy "dmesg"-emissions that accompany going to= S3 sleep, but the dmesg-output that I can collect ends slightly before the system actually sleeps, so wether anything is emitted upon the wake-up attempt, I have no w= ay to know.
Created attachment 134842 [details]
dmesg of system before it fails to resume from S3 sleep
(In reply to dwagner from comment #0) > After I updated my kernel to > https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-stagin= g-drm-next as of > today (latest commit at this time:=20 > 1c630e83443a0f271c192ecfa0d94023661a0000) I noticed that my computer w= ould > no longer wake up from S3 sleep - power LED goes on, but apart from th= at no > display and no reaction to any input (other than Num-Lock still switch= able). >=20 > The difference to the ~2 weeks older kernel was 100% reproducable by j= ust > doing: >=20 > - boot to console (no start of X11 required) and login as root > - echo "mem" >/sys/power/state > - wait till power LED blinks > - press some key to wake up the system > - observe no display output and no reaction to anything >=20 > GPU is a RX 460, CPU a Ryzen R7 1800X, board Asus X370 Pro, connected = is one > 4k display via HDMI 2.0. >=20 > I bisected the git commits, and the one that causes the bug is: >=20 > > 7ae4acd21e9e264afb079e23d43bcf2238c7dbea > > drm/amd/display: Match actual state during S3 resume. >=20 > After this, I went back to the current HEAD of amd-staging-drm-next and > (manually) reverted only commit 7ae4acd21e9e264afb079e23d43bcf2238c7db= ea, > and this indeed results in a kernel that works fine with regards to re= suming > from S3 sleep. >=20 > There are no noteworthy "dmesg"-emissions that accompany goi= ng to S3 sleep, > but the dmesg-output that I can collect ends slightly before the system > actually sleeps, so wether anything is emitted upon the wake-up attemp= t, I > have no way to know. Thanks, we can reproduce this too, should have something shortly.
(In reply to Jordan L from comment #2) > Thanks, we can reproduce this too, should have s= omething shortly. Any news on this? I am asking, because the current head of https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-staging-drm= -next (as of commit d66bebab317cc56a2a6d2438fcd89870c3d172ca) still has this very bug - = and that is even though within "git log" I can see in commit 26c860d5579684528114c3875ef88f7796330eb5 there was > Revert "drm/amd/display: Match actual state= during S3 resume." so I currently know of no way to make the current amd-staging-drm-next resu= me from S3 sleep.
(In reply to dwagner from comment #3) > (In reply to Jordan L from comment #2) > > Thanks, we can reproduce this too, should have something shortly. >=20 > Any news on this? >=20 > I am asking, because the current head of > https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-stagin= g-drm-next (as of > commit d66bebab317cc56a2a6d2438fcd89870c3d172ca) still has this very b= ug - > and that is even though within "git log" I can see in commit > 26c860d5579684528114c3875ef88f7796330eb5 there was > > Revert "drm/amd/display: Match actual state during S3 resume= ." > so I currently know of no way to make the current amd-staging-drm-next > resume from S3 sleep. S3 starts working since commit 95539e2be57.=20 Test is performed on the following condition: Commit: c6f284d9888 Asic: Baffin 4K display: Acer H277HK S3 passed in 10 runs Please verify at your side as well. Thanks.
(In reply to Jerry Zuo from comment #4) > S3 starts working since commit 95539e2be57.=20 >=20 > Test is performed on the following condition: > Commit: c6f284d9888 > Asic: Baffin > 4K display: Acer H277HK > S3 passed in 10 runs >=20 > Please verify at your side as well. Thanks. I would love to verify this - but where can I find commit 95539e2be57 ? It is not included in any branch of the https://cgit.freedes= ktop.org/~agd5f/linux/ repository as of this moment - can you point me to a repository that includes it?
= https://cgit.freedesktop.org/~agd5f/linux/commit/?h=3Damd-staging-drm-next&= amp;id=3Dc2a899da6d8c0658c6f8493cb6b5ca4e890a15b7
or for drm-next: https://cgit.freedeskto= p.org/~airlied/linux/commit/?h=3Ddrm-next&id=3Dce1b1b66cd5ec60927c57585= 8430c099b8b4bceb
Thanks, Alex. Just in order to be able to help myself next time: How does one get from knowing the string "95539e2be57" to the commits you linked? (Will try amd-staging-drm-next right now and follow up with the result after rebooting.)
Bad news: Tried amd-staging-drm-next as of commit 367a3d2bdc27fd1d23be9ea75cec34b52297184d, which does include the commit https://cgit.= freedesktop.org/~agd5f/linux/commit/?h=3Damd-staging-drm-next&id=3Dc2a8= 99da6d8c0658c6f8493cb6b5ca4e890a15b7 referenced by Alex above, but the result is still the same as in the origin= al description of this bug report. I tested "echo "mem" >/sys/power/state" both without= starting X and from an Xterm, in both cases no picture comes up at resume from S3, and the computer does not react on input. The test scenario Jerry Zuo described above does not mention whether the display was connected via DP or HDMI - could this be of relevance for reproduction?
(In reply to dwagner from comment #9) > Bad news: Tried amd-staging-drm-next as of commit > 367a3d2bdc27fd1d23be9ea75cec34b52297184d, which does include the commit > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=3Damd-stagi= ng-drm- > next&id=3Dc2a899da6d8c0658c6f8493cb6b5ca4e890a15b7 referenced by A= lex above, > but the result is still the same as in the original description of thi= s bug > report. >=20 > I tested "echo "mem" >/sys/power/state" both wi= thout starting X and from an > Xterm, in both cases no picture comes up at resume from S3, and the co= mputer > does not react on input. >=20 > The test scenario Jerry Zuo described above does not mention whether t= he > display was connected via DP or HDMI - could this be of relevance for > reproduction? I tested on HDMI in 4K display. I'll check the commit on drm-next.
Just for you information: S3 resumes still do not work in 100%= of attempts, also with the current git version of https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-staging-drm= -next This is really frustrating. 3 months after this bug first appeared (and by = that time was revertable by backing out the commit that caused it), all contempo= rary kernel versions, both from git and mainline, fail to resume from S3 all the time. I guess I will have to buy a different GPU :-(
Can you try blacklisting amdgpu and try S3 again? We've seen issues with S3 on 4.15 RCs outside of amdgpu where the system wouldn't come back from S3. It's fixed in more recent RCs (definitely 4.15-= rc6 and newer) but the issue might still be there in amd-staging-drm-next.
(In reply to Harry Wentland from comment #12) > Can you try blacklisting amdgpu and try S3 again= ? (Assuming you mean adding "module_blacklist=3Damdgpu" on the kern= el command line:) Sure, here is what happenes: kernel old =3D amd-staging-drm-next as of early October 2017 kernel new =3D amd-staging-drm-next as of this week amdgpu kernel blacklisted symptom after S3 resume -------------------------------------------------------- old no resumes fine every time old yes no HDMI signal, but system runs otherwise new no no HDMI signal, system crashes every time new yes no HDMI signal, but system runs otherwise > We've seen issues with S3 on 4.15 RCs outside of= amdgpu where the system > wouldn't come back from S3. It's fixed in more recent RCs (definitely > 4.15-rc6 and newer) but the issue might still be there in > amd-staging-drm-next. Hmmm. Would "drm-next-4.16" include this fix?
The regression was caused by: commit ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 (refs/bisect/bad) Author: Andy Lutomirski <luto@= ;kernel.org> Date: Wed Nov 22 20:39:16 2017 -0800 x86/entry/64: Add missing irqflags tracing to native_load_gs_index() I'm not sure what commit fixed it off hand.
It was supposedly fixed in -rc6 so my drm-next branches don't = have the fix yet.
I noticed in the git log of amd-staging-drm-next that multiple= patches were committed that might be related to S3 resumes, so I retried whether a kernel compiled from the current amd-staging-drm-next head is able to resume from S3. Unluckily, the symptoms are unchanged: System crashes upon every S3 resume attempt - so I'm back to the kernel from last October that resumes fine. With relevant security issues having been addressed in the kernel between Oct 17 and now this situation becomes unbearable for me. Patches that were included in the kernel I tried today: > commit f8c80313f7a6a8f66b74b118b0e3e5112718e2e5 = (HEAD, origin/amd-staging-drm-next) > Author: Alex Deucher <alexander.deucher@amd.com> > Date: Thu Feb 15 08:40:30 2018 -0500 > Revert "drm/radeon/pm: autoswitch power state when in balanced = mode" > This reverts commit 1c331f75aa6ccbf64ebcc5a019183e617c9d818a. > Breaks resume on some systems. > commit 734b7ebc0e16b0fb4d2937cc3716c505d7e2c319 > Author: Hersen Wu <herse= nxs.wu@amd.com> > Date: Tue Jan 30 11:46:16 2018 -0500 >=20 > drm/amd/display: VGA black screen from s3 when attached to hook=20= =20=20=20 > [Description] For MST, DC already notify MST sink for MST mode, DC = stll > check DP SINK DPCD register to see if MST enabled. DP RX firmware m= ay > not handle this properly. > commit adf1c840a6741f1b53ecd6e466e160c725a80641 > Author: Yongqiang Sun <yongqiang.sun@amd.com> > Date: Fri Feb 2 17:35:00 2018 -0500 > drm/amd/display: Keep eDP stream enabled during boot. >=20=20=20 > This path fixed specific eDP panel cold boot black screen > due to unnecessary enable link. > Change: > In case of boot up with eDP, if OS is going to set mode > on eDP, keep eDP light up, do not disable and reset corresponding > HW. > This change may affect dce asics and S3/S4 Resume with multi-monitor= . > commit 8dd8b6bb22fb2470af4e8743f19eabba8127d566 > Author: Charlene Liu <c= harlene.liu@amd.com> > Date: Wed Jan 24 13:18:57 2018 -0500 >=20 > drm/amd/display: resume from S3 bypass power down HW block. > commit 8d0de6a585e2186734748be2a1043eb3456ed8ed > Author: Mikita Lipski <mikita.lipski@amd.com> > Date: Sat Feb 3 15:19:20 2018 -0500 > drm/amdgpu: Unify the dm resume calls into one >=20=20 > amdgpu_dm_display_resume is now called from dm_resume to > unify DAL resume call into a single function call >=20=20=20 > There is no more need to separately call 2 resume functions > for DM. >=20=20=20 > Initially they were separated to resume display state after > cursor is pinned. But because there is no longer any corruption > with the cursor - the calls can be merged into one function hook.
amd-staging-drm-next is still based on 4.15-rc4 which still ha= s the regression mentioned in comment 14. Can = you try 4.15 final or my drm-next-4.17-wip branch?
(In reply to Alex Deucher from comment #17) > amd-staging-drm-next is still based on 4.15-rc4 = which still has the > regression mentioned in comme= nt 14. Can you try 4.15 final or my > drm-next-4.17-wip branch? Just did this - but no change of symptoms, still crash upon every S3 resume attempt.
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
Hi dwagner, I have attempted to reproduce an issue, but didn't succeed. We have used an identical hardware setup with a reference rx460 card and couldn't reproduce a hang on various kernel versions. There is still a possibility that some kernel config options might be causi= ng an issue.=20 If its possible, could you please provide kernel configuration so the testi= ng environment is identical. Also does the issue reproduce reproduce if you disable DC? (amdgpu.dc=3D0 i= n GRUB menu) Thanks=20 Nik
(In reply to miki= ta.lipski@amd.com from com= ment #19) > I have attempted to reproduce an issue, but didn= 't succeed. > We have used an identical hardware setup with a reference rx460 card a= nd > couldn't reproduce a hang on various kernel versions. Strange. If I didn't keep an older amd-staging-drm-next kernel from October 2017 in use where S3 resumes work every time, I would doubt my hardware - b= ut the way it is the only possible cause is a kernel change sine then. > There is still a possibility that some kernel co= nfig options might be > causing an issue.=20 > If its possible, could you please provide kernel configuration so the > testing environment is identical. Sure, will attach my .config (as used with the current drm-next-4.17-wip) a= fter this comment. > Also does the issue reproduce reproduce if you d= isable DC? (amdgpu.dc=3D0 in > GRUB menu) Tested with today's drm-next-4.17-wip git: With "amdgpu.dc=3D0" o= n the kernel command line, resume from S3 works fine for me, both from the console (befo= re starting X11) and when running X11. (But of course, no 4k/60Hz video and no HDMI audio with amdgpu.dc=3D0, so t= hat is not really an option for actual use.) So the resume-from-S3 failures are definitely caused by something in the DC code that changed since early October 2017.
Created attachment 138169 [details]
kernel .config as used with git at commit
61deb7d0dddd941d1e3ffee0d799396ac93b0e90 (HEAD, origin/drm-next-4.17-wip)