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

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #32 from Duncan (1i5t5.duncan@cox.net) ---
Created attachment 289911
  --> https://bugzilla.kernel.org/attachment.cgi?id=289911&action=edit
Partial git bisect log

(In reply to zzyxpaw from comment #29)
> @Duncan I'm not sure if you want to muddle your
> bisect results with a different system configuration, but I'm happy to help
> test commits if that would be helpful.

Here's my current git bisect log you can replay.

I believe that should leave you at v5.6-rc2-245-gcf6c26ec7, which I'm going to
build and boot to as soon as I post this.

But if your system's as good at triggering the bug as you suggest, try deleting
that last good before the replay as I'm only ~98% sure about it given a
potential trigger-time of days on my system.  That should leave you at
7be97138e which you can try triggering it with.  If your system's reliably
triggering within minutes and it doesn't trigger on that, you can confirm my
bisect good and go from there.

Note that if you're building with gcc-10.x you'll likely need a couple patches
that were committed later in the 5.7 cycle, depending on if if they were
applied before or after whatever you're testing.  If you're building with
gcc-9.3 (and presumably earlier) they shouldn't be necessary.

a9a3ed1ef and e78d334a5 are the commits in question.  One was necessary to
build with gcc-10, the other to get past a boot-time crash when built with
gcc-10.  Only one's applying at cf6c26ec7, I don't remember which, but they
were both necessary for 7be97138e.

At my somewhat limited git skill level it was easiest to redirect a git show of
the commit to a patchfile, then apply the patch on top of whatever git bisect
gave me and git reset --hard to clean up the patches before the next git bisect
good/bad.  I guess a git cherry-pick would be the usual way to apply them but
I'm not entirely sure how that interacts with git bisect, so applying the
patches on top was easier way for me, particularly given that I already have
scripts to automate patch application for my local default-to-noatime patch.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel