<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921" href="https://bugs.freedesktop.org/show_bug.cgi?id=107065#c20">Comment # 20</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921" href="https://bugs.freedesktop.org/show_bug.cgi?id=107065">bug 107065</a> from <a class="email" href="mailto:jb5sgc1n.nya@20mm.eu" title="dwagner <jb5sgc1n.nya@20mm.eu>"> dwagner</a> <pre>(In reply to Andrey Grodzovsky from <a href="show_bug.cgi?id=107065#c19">comment #19</a>) > I was able to reproduce this instantly without even using page tables CPU > update mode. Looks like a regression since S3 was working fine for long > time. Were you able to find a regression point for this ? Not for the exact symptom described in this report, but for an older S3 resume issue that was partially resolved - <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit" href="show_bug.cgi?id=103277">https://bugs.freedesktop.org/show_bug.cgi?id=103277</a> - I did once find the regression caused by the "drm/amd/display: Match actual state during S3 resume" commit. Unluckily, the many changes that followed thereafter do no longer allow to bisect the symptom there to one specific commit, but given that it still occurs if I use the option "drm.edid_firmware=edid/LG_EG9609_edid.bin", I think there is still some bug in the order of things done during re-initialization upon S3 resumes, and setting some fixed EDID seems to expose it as crash.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>