| Bug ID | 111922 |
|---|---|
| Summary | amdgpu fails to resume on 5.2 kernel [regression] |
| Product | DRI |
| Version | DRI git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | not set |
| Priority | not set |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | pierre-bugzilla@ossman.eu |
The upgrade to the 5.2 series of the kernel has unfortunately = made my system unusable. After resuming the system from suspend the display goes green and= is unresponsive locally. It is still up though so I was able to reach it via t= he network and get some logs out of it. Tested bad kernels: 5.2.15-200.fc30 5.2.9-200.fc30 Known good kernels: 5.0.17-300.fc30 5.1.18-300.fc30 5.1.20-300.fc30 Found some other bug reports both here and with Red Hat with similar warnin= gs in dmesg, but they seem to be failing right away and not after a suspend. So I'm not sure if it's the same issue. But report at Red Hat: https://b= ugzilla.redhat.com/show_bug.cgi?id=3D1754252 (includes dmesg)
Not easily unfortunately as I've only been using Fedora kernel= s, so I don't have a build environment set up.
Issue still remains with 5.4.0-rc6 unfortunately. :/ Do you have any patches or commits I could try reverting? It's much easier building a test RPM here. It should be something during the 5.2.0 merge window. Anything likely from = that set?
That's a shame. I did find bug 111811, which looks very simil= ar. Through that I found this patch: https://www.mail-archive.com/amd-gfx@lists.freedesktop.or= g/msg40304.html Unfortunately it does not solve the issue here. :/ Have you checked if you can reproduce this in a 2200G in your end? Or other Raven Ridge APUs?
Hmmm... I did get this from that patch though:
> [ 98.391016] amdgpu 0000:38:00.0: GPU mode1 re=
set
> [ 98.391072] [drm] psp mode 1 reset not supported now!=20
> [ 98.391074] amdgpu 0000:38:00.0: GPU mode1 reset failed
> [ 98.391151] amdgpu 0000:38:00.0: GPU mode1 reset
> [ 98.391198] [drm] psp mode 1 reset not supported now!=20
> [ 98.391199] amdgpu 0000:38:00.0: GPU mode1 reset failed
> [ 98.391358] [drm:amdgpu_device_suspend [amdgpu]] *ERROR* amdgpu asi=
c reset failed
Not sure if it helps.
I finally got a build environment set up, and the winner is:
> df8368be1382b442384507a5147c89978cd60702 is the =
first bad commit
> commit df8368be1382b442384507a5147c89978cd60702
> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> Date: Wed Feb 27 12:56:36 2019 -0500
>=20
> drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates
>=20=20=20=20=20
> To help xf86-video-amdgpu and mesa know DC supports updating the
> tiling attributes for a framebuffer per-flip.
>=20=20=20=20=20
> Cc: Michel D=C3=A4nzer <michel@daenzer.net>
> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
> Reviewed-by: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>=20
> :040000 040000 06a7975c484e74ebdaa4ccf9ee1dc5dac7a0abc9 ab68acde511d49=
b3f96818066bba35f255ce1656 M drivers
Which seems extremely odd given the contents of that commit. But I guess it
makes userspace change behaviour in a way that provokes the bug?
I don't think bisect will get me further. Help?
(In reply to Pierre Ossman from comment #7) > I finally got a build environment set up, and th= e winner is: >=20 > > df8368be1382b442384507a5147c89978cd60702 is the first bad commit > > commit df8368be1382b442384507a5147c89978cd60702 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Feb 27 12:56:36 2019 -0500 > >=20 > > drm/amdgpu: Bump amdgpu version for per-flip plane tiling upd= ates > >=20=20=20=20=20 > > To help xf86-video-amdgpu and mesa know DC supports updating = the > > tiling attributes for a framebuffer per-flip. > >=20=20=20=20=20 > > Cc: Michel D=C3=A4nzer <michel@daenzer.net> > > Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Acked-by: Alex Deucher <alexander.deucher@amd.com> > > Reviewed-by: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com> > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > >=20 > > :040000 040000 06a7975c484e74ebdaa4ccf9ee1dc5dac7a0abc9 ab68acde5= 11d49b3f96818066bba35f255ce1656 M drivers >=20 > Which seems extremely odd given the contents of that commit. But I gue= ss it > makes userspace change behaviour in a way that provokes the bug? >=20 > I don't think bisect will get me further. Help? Userspace only enables per flip tiling updates if the version of the kernel driver is new enough to support that feature. Maybe this is related to the= DCC changes in mesa.
Userspace doesn't know when suspend/resume is happening, so it= can't hang on suspend/resume. My guess is it's something in DAL.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/931.