[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #22 from Duncan (1i5t5.duncan at cox.net) ---
(In reply to rtmasura+kernel from comment #21)
> OK. I've uninstalled the vast majority of KDE and am using a vanilla XFCE4.
> It's been about 12 hours on 5.7.4-arch1-1 and I have yet to have a crash. It
> is looking like it may be something with KDE.

Note that it is possible to run kwin (kwin_x11 being the actual executable) on
another desktop, or conversely, a different WM on plasma.  To run kwin and make
it replace the existing WM you'd simply type in (in the xfce runner or terminal
window, it can be done from a different VT as well but then you gotta feed kwin
the display information too) kwin_x11 --replace.  Presumably other WMs have a
similar command-line option.

I've never actually done it on a non-plasma desktop (tho I run live-git plasma
and frameworks so I must always be prepared to restart it or various other
plasma components, to the point I have non-kde-invoked shortcuts setup to do it
there), but I /think/ kwin would continue to use the configuration setup on
kde, the various window rules, configured kwin keyboard shortcuts and effects,
etc.

That could prove whether it's actually kwin triggering or not (tho it's a
kernel bug regardless), tho I suspect the proof is academic at this point given
that you've demonstrated that the trigger does appear to be kde/plasma related,
at least.  IMO kwin triggering is a reasonably safe assumption given that.  But
it does explain why the bug isn't widely reported, plasma being the apparent
biggest trigger and limited to specific now older generations of hardware means
few people, even of those running the latest kernels, are going to see it.

Meanwhile, I actually got a log-dump on the 4th crash of the kernel at that
bisect step, confirming it is indeed this bug, and have advanced a bisect step.
 But git says I still have ~11 steps, 1000+ commits, so it's still well too
large to start trying to pick out candidate buggy commits from the remainder. 
Slow going indeed.  At this rate a full bisect and fix could well be after 5.8
release, giving us two full bad release cycles and kernels before a fix.  Not
good. =:^(

-- 
You are receiving this mail because:
You are watching the assignee of the bug.