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? 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. 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? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- A non-text attachment was scrubbed... Name: kern.log Type: text/x-log Size: 9635 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20171108/b60fa43c/attachment.bin>
