Op 07-08-13 02:05, Dave Airlie schreef:
> On Tue, Jul 30, 2013 at 6:41 PM, Peter Zijlstra wrote:
>> On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
>>> The check needs to be for > 1, because ctx->acquired is already incremented.
>>> This will prevent ww_mutex_lock_slow from retu
On Tue, Jul 30, 2013 at 6:41 PM, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
>> The check needs to be for > 1, because ctx->acquired is already incremented.
>> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
>> the mutex.
On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_
On Tue, Jul 30, 2013 at 4:13 AM, Maarten Lankhorst
wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_DEBUG_WW
On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_
The check needs to be for > 1, because ctx->acquired is already incremented.
This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
the mutex. It caused a lot of false gpu lockups on radeon with
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
to retu
6 matches
Mail list logo