Op 02-07-2020 om 16:51 schreef Tvrtko Ursulin:
> On 02/07/2020 14:26, Maarten Lankhorst wrote:
>> Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>>> On 24/06/2020 12:05, Maarten Lankhorst wrote:
Killing context before taking ctx->mutex fixes a hang in
gem_ctx_persistence.close-replace-rac
On 02/07/2020 14:26, Maarten Lankhorst wrote:
> Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>>
>> On 24/06/2020 12:05, Maarten Lankhorst wrote:
>>> Killing context before taking ctx->mutex fixes a hang in
>>> gem_ctx_persistence.close-replace-race, where lut_close
>>> takes obj->resv.lock which
Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>
> On 24/06/2020 12:05, Maarten Lankhorst wrote:
>> Killing context before taking ctx->mutex fixes a hang in
>> gem_ctx_persistence.close-replace-race, where lut_close
>> takes obj->resv.lock which is already held by execbuf,
>> causing a stalling ind
On 24/06/2020 12:05, Maarten Lankhorst wrote:
Killing context before taking ctx->mutex fixes a hang in
gem_ctx_persistence.close-replace-race, where lut_close
takes obj->resv.lock which is already held by execbuf,
causing a stalling indefinitely.
If this is the consequence of inverting the lo
Killing context before taking ctx->mutex fixes a hang in
gem_ctx_persistence.close-replace-race, where lut_close
takes obj->resv.lock which is already held by execbuf,
causing a stalling indefinitely.
[ 1904.342847] 2 locks held by gem_ctx_persist/11520:
[ 1904.342849] #0: 8882188e4968 (&ctx-
