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

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Sat Jun 27 07:07:39 UTC 2020


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

--- Comment #28 from Duncan (1i5t5.duncan at cox.net) ---
(In reply to rtmasura+kernel from comment #27)
> and another crash, chrome's good at causing them (watching youtube). Used -s
> "" for the setting which I think should set it to 'auto', and what I assumed
> was default. I've changed that to -s "off" to see if that helps.

You just added those updates as I was typing a comment pointing out that
chrome/chromium in your bug; bugzilla warned of a mid-air collision! 
Chrom(e|ium) has new vulkan accel code and very likely exercises some of the
same relatively new amdgpu kernel code kwin does, so both of them triggering
the bug wouldn't surprise me at all.

As it happens I switched back to firefox during the 5.6 kernel cycle, so
haven't seen chromium's interaction with the (kernel 5.7) bug myself, but once
I saw it in that trace I said to myself I bet that's his trigger!


FWIW I advanced a couple more bisect steps pretty quickly as it was triggering
as I tried to complete system updates (which on gentoo of course means building
the packages), but then I hit an apparently good kernel, and uptime says 3 days
now, something I've not seen in awhile!  Only thing is, I finished those
updates and they were pretty calm the next couple days, so I've not been
stressing the system to the same extent, either.  Given the problems I got
myself into the first bisect run, I'm going to run on this kernel a bit longer
before I do that bisect good to advance a step.  If it reaches a week and I've
done either a good system update or a some heavy 4k at 60 youtube on firefox, I'll
call it good, but I'm not ready to yet.

The good news is, in a couple more bisect steps I'll be down to some practical
number of remaining commits to report the range here, and if they have the
time, a dev with a practiced eye should be able to narrow it down by say 3/4
(two steps ahead of my bisect), leaving something actually practical to examine
closer.  After that it'll be past the point of my bisect being the only
bottleneck, if it's big enough to get dev priority time, of course.  If not,
I'll just have to keep plugging away at the bisect...

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


More information about the dri-devel mailing list