On Sat, 17 Sep 2011 20:55:44 +0200
Daniel Vetter wrote:
> Hi all,
>
> Original bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=38115
>
> This bug can e.g. be hit with glBufferData(dst, glBufferMap(src))
>
> Testcase is gem_mmap_gtt.
>
> Neglecting the trivial cleanup patch 2, patch 1
On Sat, 17 Sep 2011 20:55:49 +0200, Daniel Vetter
wrote:
> Like for shmem_pwrite_slow. The only difference is that because we
> read data, we can leave the fetched cachelines in the cpu: In the case
> that the object isn't in the cpu read domain anymore, the clflush for
> the next cpu read domain
On Sat, 17 Sep 2011 20:55:48 +0200, Daniel Vetter
wrote:
> ... instead of get_user_pages, because that fails on non page-backed
> user addresses like e.g. a gtt mapping of a bo.
>
> To get there essentially copy the vfs read path into pagecache. We
> can't call that right away because we have to
On Sat, 17 Sep 2011 20:55:47 +0200, Daniel Vetter
wrote:
> The gtt_pwrite slowpath grabs the userspace memory with
> get_user_pages. This will not work for non-page backed memory, like a
> gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
> -EFAULT in the gtt paths.
>
> Now
On Sat, Sep 17, 2011 at 08:55:48PM +0200, Daniel Vetter wrote:
> out:
> - for (i = 0; i < pinned_pages; i++)
> - page_cache_release(user_pages[i]);
> - drm_free_large(user_pages);
> + mutex_lock(&dev->struct_mutex);
> + /* Fixup: Kill any reinstated backing storage page
On Sat, 17 Sep 2011 20:55:46 +0200, Daniel Vetter
wrote:
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.fr
On Sat, 17 Sep 2011 20:55:45 +0200, Daniel Vetter
wrote:
> For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
> pagefault_disable/_enable. The i915 driver relies on the map
> actually being atomic, otherwise it can deadlock with it's own
> pagefault handler in the gtt pwrite fastpath
Like for shmem_pwrite_slow. The only difference is that because we
read data, we can leave the fetched cachelines in the cpu: In the case
that the object isn't in the cpu read domain anymore, the clflush for
the next cpu read domain invalidation will simply drop these
cachelines.
slow_shmem_bit17_
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault
The gtt_pwrite slowpath grabs the userspace memory with
get_user_pages. This will not work for non-page backed memory, like a
gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
-EFAULT in the gtt paths.
Now the shmem paths have exactly the same problem, but this way we
only nee
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/i915_gem_debug.c |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9857e9d..e0475ca 100644
-
For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
pagefault_disable/_enable. The i915 driver relies on the map
actually being atomic, otherwise it can deadlock with it's own
pagefault handler in the gtt pwrite fastpath.
This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
t
Hi all,
Original bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=38115
This bug can e.g. be hit with glBufferData(dst, glBufferMap(src))
Testcase is gem_mmap_gtt.
Neglecting the trivial cleanup patch 2, patch 1 converts the possible
deadlock in an errornous -EFAULT. I've already submitt
OpenGL renderer string: Gallium 0.4 on i915 (chipset: 915GM)
you likely don't want to be using that. Use the supported classic i915
driver instead.
Well, I have at least two working kernel/Xorg/etc installations at hand.
Or is there a special reason why Gallium should not be tested on the i
Am 17.09.2011 14:31, schrieb Daniel Vetter:
Yeah, the i915g drivers has probably a few memory corruption issues left.
Can you recompile with debug support (--enable-debug) and run glxgears in
valgrind and then post the output? Maybe also file a bug against the i915
gallium driver on freedesktop.o
Yeah, the i915g drivers has probably a few memory corruption issues left.
Can you recompile with debug support (--enable-debug) and run glxgears in
valgrind and then post the output? Maybe also file a bug against the i915
gallium driver on freedesktop.org.
Thanks, Daniel
On Sat, Sep 17, 2011 at 0
On Sat, Sep 17, 2011 at 14:14:39 +0200, Knut Petersen wrote:
> OpenGL renderer string: Gallium 0.4 on i915 (chipset: 915GM)
you likely don't want to be using that. Use the supported classic i915
driver instead.
Cheers,
Julien
___
Intel-gfx mailing lis
Every time I start firefox 6.0.2 I see a segfault in /var/log/messages:
===
Sep 11 08:18:42 golem kernel: [133705.542630] firefox-bin[15419]: segfault at 0
ip (null) sp bf886dec error 14 in firefox-bin[8048000+c000]
Sep 17 13:16:30 golem kernel:
18 matches
Mail list logo
