<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460" href="https://bugs.freedesktop.org/show_bug.cgi?id=99275#c13">Comment # 13</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460" href="https://bugs.freedesktop.org/show_bug.cgi?id=99275">bug 99275</a> from <a class="email" href="mailto:tuxuser@quantentunnel.de" title="Reimar Imhof <tuxuser@quantentunnel.de>"> Reimar Imhof</a> <pre>after I've had seen, 4.8 hat the same problem I tried to find the first good 4.8.x: > git bisect new 107d026ae1c80ac0881f791a58cd115321d111ca is the first new commit commit 107d026ae1c80ac0881f791a58cd115321d111ca Author: Will Deacon <<a href="mailto:will.deacon@arm.com">will.deacon@arm.com</a>> Date: Fri Aug 26 11:36:39 2016 +0100 arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP commit 3a402a709500c5a3faca2111668c33d96555e35a upstream. When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state. Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction. This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread. Cc: <<a href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a>> Reported-by: Yao Qi <<a href="mailto:yao.qi@arm.com">yao.qi@arm.com</a>> Signed-off-by: Will Deacon <<a href="mailto:will.deacon@arm.com">will.deacon@arm.com</a>> Signed-off-by: Greg Kroah-Hartman <<a href="mailto:gregkh@linuxfoundation.org">gregkh@linuxfoundation.org</a>> :040000 040000 98b6a8a0d27ab29b17b6b617e52beb33d56dc604 46030e41ff5783555a6d6e895799aabbe3a0c46e M arch</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>