[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon at bugzilla.kernel.org]

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

--- Comment #20 from Bernd Steinhauser (linux at bernd-steinhauser.de) ---
(In reply to Christian König from comment #17)
> We completely disabled the feature added in "5d35ed4832d" for upstreaming
> later on.
> 
> Can you guys please test amd-staging-drm-next as well and check if the
> problem occurs there as well. If not then please bisect what fixed it.
Would've been nice to point me to the corresponding repo as well.
Don't worry, I've figured it out, but still would've been nice.
In any case, current HEAD of amd-staging-drm-next looks good to me, I can't
reproduce the memleaks with that one.

I'll try to find the fix, but that'll take me 2-3 days.

(In reply to Paul Menzel from comment #18)
> Bernd, if you have time, it’d be great, if you listed the commits here,
> which you needed to apply on top to fix the other regressions.
Most importantly 9d27e39d309c93025ae6aa97236af15bef2a5f1f, which says it's for
Carrizo, but it seems to affect my Kaveri as well, which wouldn't be surprising
since the two are related.
But on your Ryzen(?) system, this one might not be necessary.
I also applied 03651735fbded39f608163718f816ab9cf14fba7 on top for a wider
range of commits after 972a21f94631642d6714bb2a1983b7b15a77526d since otherwise
the system would freeze very quickly.
But even with that one applied the mentioned id above is very unstable and I
have only about 1min or so to do my tests.
Still that was enough time to do the tests at least twice and show that there
is the same flood of memory leaks with pretty much the same function sequences.

(In reply to Christian König from comment #19)
> 
> Commit 5d35ed4832d is a bug fix for bulk moves, which is a feature which
> should be completely disabled in 4.20. So your bisecting is most likely
> incorrect.
> 
Well, as I said, I'm not 100% sure, because I had to apply two patches to be
even able to test.
But I've repeated my tests with those two versions earlier on and came to the
same result.
b995795bf09b6bb7847a2a9fc8e6b5b4ab0ce20c does show exactly 6 memleaks to me and
those are the 2 acpi ones I mentioned above and 4 showing hid function
sequences, but nothing with drm or similar.
One commit later (5d35ed4832d) with the same two patches applied it's a
different story and I get 60 or more memleaks listed, which you have to admit
look an awful lot similar to what I've posted for 5.0-rc1 above (I'll upload
the log in a minute).
Now that could be pure coincidence, but I would be surprised if it was.

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