On Wed, 2017-01-11 at 10:25 -0800, Matt Turner wrote:
> Coverity thinks there are some bad shifts introduced by commit c2acf97.
>
> I think it thinks that first can be 64 because 64 is the greatest
> value that can be returned by ffsll(), but that's not actually
> possible? If that's correct, mayb
Coverity thinks there are some bad shifts introduced by commit c2acf97.
I think it thinks that first can be 64 because 64 is the greatest
value that can be returned by ffsll(), but that's not actually
possible? If that's correct, maybe an assert is in order.
** CID 1398563:(BAD_SHIFT)
/src/me
On 16/11/16 01:35, Jordan Justen wrote:
On 2016-11-15 16:21:27, Matt Turner wrote:
Jordan,
In
commit 0041169cacb300a882b4dc38cd341f98bf2a7c38
Author: Jordan Justen
Date: Fri Oct 21 12:56:49 2016 +0100
This date is not correct. In my branch it was:
Date: Mon Jun 30 00:50:56 2014 +
Y
On Tue, Nov 15, 2016 at 5:35 PM, Jordan Justen
wrote:
> On 2016-11-15 16:21:27, Matt Turner wrote:
>> Jordan,
>>
>> In
>>
>> commit 0041169cacb300a882b4dc38cd341f98bf2a7c38
>> Author: Jordan Justen
>> Date: Fri Oct 21 12:56:49 2016 +0100
>>
>
> This date is not correct. In my branch it was:
>
>
On 2016-11-15 16:21:27, Matt Turner wrote:
> Jordan,
>
> In
>
> commit 0041169cacb300a882b4dc38cd341f98bf2a7c38
> Author: Jordan Justen
> Date: Fri Oct 21 12:56:49 2016 +0100
>
This date is not correct. In my branch it was:
Date: Mon Jun 30 00:50:56 2014 +
I wonder how the date got rese
Jordan,
In
commit 0041169cacb300a882b4dc38cd341f98bf2a7c38
Author: Jordan Justen
Date: Fri Oct 21 12:56:49 2016 +0100
i965: Wrap MCS miptree in intel_miptree_aux_buffer
you changed intel_miptree_alloc_mcs() to return mt->mcs_buf != NULL.
mt->mcs_buf is assigned a few lines higher the re
On 13 April 2016 at 22:03, Dongwon Kim wrote:
> There are four different places where the program pointer may jump to
> 'cleanup:' while the mutex is still possilby being locked. Two
> of those cases are when mtx_lock(pthread_mutex_lock) fails to lock
> the mutex. However, this can't be a problem
There are four different places where the program pointer may jump to
'cleanup:' while the mutex is still possilby being locked. Two
of those cases are when mtx_lock(pthread_mutex_lock) fails to lock
the mutex. However, this can't be a problem because the mutex is either
not in "locked" state be
Looks like some locking problems caused by commit 70299474. Please take a look.
-- Forwarded message --
From:
Date: Wed, Apr 13, 2016 at 8:37 AM
Subject: New Defects reported by Coverity Scan for Mesa
__
