Am 08.11.2017 um 18:37 schrieb Michel Dänzer:
On 08/11/17 05:41 PM, Christian König wrote:
Am 08.11.2017 um 17:36 schrieb Michel Dänzer:
On 08/11/17 03:59 PM, Christian König wrote:
Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.
Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.
Ok in this case let's call this confusing. But yeah that
__ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
ww_mutex_unlock(&bo->resv->lock) are essentially the same thing is
exactly what I want to fix here.
How about always using __ttm_bo_unreserve instead?
I actually want to get rid of __ttm_bo_reserve as well. Cause what is
easier to understand:
__ttm_bo_reserve(bo, false, false, NULL) vs.
reservation_object_lock(bo->resv);
__ttm_bo_reserve(bo, false, true, NULL) vs.
reservation_object_trylock(bo->resv);
__ttm_bo_reserve(bo, true, false, NULL) vs.
reservation_object_lock_interruptible(bo->resv);
The first piglit run with this series applied hit the BUG_ON in
ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
couldn't reboot cleanly. Haven't been able to reproduce it in three more
attempts though, so I'm not sure it's caused by this series, but I don't
remember seeing it before.
It's most likely caused by this change, I will take another look tomorrow.
P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
kernels for a while, I'll enable it again. Any other options that should
be enabled for testing?
kmemleak is quite nice to have available as well, but doesn't need to
run automatically all the time.
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
