https://bugs.freedesktop.org/show_bug.cgi?id=32406
--- Comment #9 from Kip Warner ---
Hey Ilia,
I can confirm that this is still an issue. In fact, I noticed it not just with
the Nouveau driver (Ubuntu, amd64, 1:1.0.11+git1411032101.3fb97d~gd~u), but
also with the non-free nVidia 346 driver.
I
https://bugs.freedesktop.org/show_bug.cgi?id=80901
--- Comment #35 from Martin Peres ---
(In reply to K.-P. Schrage from comment #34)
> (In reply to Martin Peres from comment #33)
>
> Hello, Martin,
>
> thank you for caring!
>
>
> # nvapeek e114 10
> e114: 021c 00d8 0001 0
Only add wrapped bo's and bo's that have been exported through flink or dma-buf.
This avoids a lock in the common case, and decreases traversal needed for
importing
a dma-buf or flink.
Signed-off-by: Maarten Lankhorst
---
nouveau/nouveau.c | 46 ++
1
While I've closed off most races in a previous patch, a small race still existed
where importing then unreffing cound cause an invalid bo. Add a test for this
case.
Racing sequence fixed:
- thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock.
- thread 2 increases refcou
Signed-off-by: Maarten Lankhorst
---
xf86atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86atomic.h b/xf86atomic.h
index 17fb088..194554c 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -50,7 +50,7 @@ typedef struct {
# define atomic_set(x, val) ((x)->atomic = (val
Signed-off-by: Maarten Lankhorst
---
xf86atomic.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xf86atomic.h b/xf86atomic.h
index 8c4b696..17fb088 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -49,6 +49,7 @@ typedef struct {
# define atomic_read(x) ((x)->atomic)
# define atomic_set(x
https://bugs.freedesktop.org/show_bug.cgi?id=80901
--- Comment #34 from K.-P. Schrage ---
(In reply to Martin Peres from comment #33)
Hello, Martin,
thank you for caring!
# nvapeek e114 10
e114: 021c 00d8 0001
(that's with the latest nouveau driver from darktama)
Af
On 25 February 2015 at 21:59, Maarten Lankhorst
wrote:
> On 25-02-15 15:14, Emil Velikov wrote:
>> On 24 February 2015 at 09:01, Maarten Lankhorst
>> wrote:
...
>>> +static const char default_device[] = "/dev/dri/renderD128";
>>> +
>> Reuse the defines in xf86drm.h ?
>
> Hmm, switching to drmOpen
Am Donnerstag, den 26.02.2015, 12:44 +0900 schrieb Alexandre Courbot:
> User-space use mappable BOs notably for fences, and expects that a
> value update by the GPU will be immediatly visible through the
> user-space mapping.
>
> ARM has a property that may prevent this from happening though: memo
