[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Bug #: 45921 Summary: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com Found while comparing piglit results between 7.11 and 8.0 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 is the first bad commit commit 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 Author: Marek Olšák Date: Sun Aug 7 19:04:37 2011 +0200 winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Reviewed-by: Alex Deucher Regressed tests: glsl1-inequality (vec2, pass) glsl-fs-discard-02 glsl-max-varyings glsl-vs-loop-redundant-condition fs-any-bvec2-using-if fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-vec2-vec2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if and probably some others All those tests pass on 7.11 and fail in both 8.0 and master branch. GPU: RV530 Kernel: 3.2.3 Libdrm: 2.4.31 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45901] [r300g, bisected] vs-atan-float-float fail
https://bugs.freedesktop.org/show_bug.cgi?id=45901 --- Comment #1 from Pavel Ondračka 2012-02-11 03:11:30 UTC --- glsl-vs-vec4-indexing-temp-dst-in-loop is another test regressed by aforementioned commit. BTW both tests pass with llvmpipe and softpipe, so this is probably just some uncovered r300 compiler bug, not a real regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #1 from Marek Olšák 2012-02-11 03:21:46 PST --- I am sure the commit in question is not the cause. I prematurely added the code for the new ioctl and disabled it later on, because my kernel code the commit was supposed to interact with wasn't accepted. The problem when bisecting is that now it tries to call a non-existing ioctl if the DRM minor version is >=12, which makes some tests fail. Could you please check dmesg to see if that's the case? There should be some error messages from DRM. I think that some of those piglit failures are caused by the glsl-to-tgsi translator. You can disable glsl-to-tgsi by commenting out: functions->LinkShader = st_link_shader; at the end of src/mesa/state_tracker/st_cb_program.c. Anyway, sorry, I won't probably help you with this bug anytime soon. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). Signed-off-by: Yufeng Shen --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_i2c.c | 23 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 559fb6f..4ed9fd9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -722,6 +722,8 @@ typedef struct drm_i915_private { u8 corr; spinlock_t *mchdev_lock; + struct mutex gmbus_mutex; + enum no_fbc_reason no_fbc_reason; struct drm_mm_node *compressed_fb; diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index d98cee6..42569b1 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct intel_gmbus, adapter); struct drm_i915_private *dev_priv = adapter->algo_data; - int i, reg_offset; + int i, reg_offset, ret; - if (bus->force_bit) - return intel_i2c_quirk_xfer(dev_priv, + mutex_lock(&dev_priv->gmbus_mutex); + + if (bus->force_bit) { + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); + goto out; + } reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0; @@ -320,7 +324,8 @@ done: * start of the next xfer, till then let it sleep. */ I915_WRITE(GMBUS0 + reg_offset, 0); - return i; + ret = i; + goto out; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", @@ -330,9 +335,13 @@ timeout: /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) - return -ENOMEM; + ret = -ENOMEM; + else + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); +out: + mutex_unlock(&dev_priv->gmbus_mutex); + return ret; } static u32 gmbus_func(struct i2c_adapter *adapter) @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev) if (dev_priv->gmbus == NULL) return -ENOMEM; + mutex_init(&dev_priv->gmbus_mutex); + for (i = 0; i < GMBUS_NUM_PORTS; i++) { struct intel_gmbus *bus = &dev_priv->gmbus[i]; -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Detect cache domain inconsistency with valgrind
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson --- intel/intel_bufmgr_gem.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 2e65580..3856d3d 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -922,6 +922,20 @@ drm_intel_gem_bo_free(drm_intel_bo *bo) free(bo); } +static void +drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo) +{ +#if HAVE_VALGRIND + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; + + if (bo_gem->mem_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_virtual, bo->size); + + if (bo_gem->gtt_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size); +#endif +} + /** Frees all cached buffers significantly older than @time. */ static void drm_intel_gem_cleanup_bo_cache(drm_intel_bufmgr_gem *bufmgr_gem, time_t time) @@ -1050,6 +1064,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time) DBG("bo freed with non-zero map-count %d\n", bo_gem->map_count); bo_gem->map_count = 0; drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); } DRMLISTDEL(&bo_gem->name_list); @@ -1160,6 +1175,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) if (write_enable) bo_gem->mapped_cpu_write = true; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->mem_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1240,6 +1257,8 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) strerror(errno)); } + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1289,6 +1308,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) */ if (--bo_gem->map_count == 0) { drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); bo->virtual = NULL; } pthread_mutex_unlock(&bufmgr_gem->lock); @@ -1615,6 +1635,8 @@ drm_intel_gem_bo_process_reloc(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc(target_bo); @@ -1639,6 +1661,8 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc2(target_bo); -- 1.7.9 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote: > Every access to either the GTT or CPU pointer is supposed to be > proceeded by a set_domain ioctl so that GEM is able to manage the cache > domains correctly and for the following access to be coherent. Of > course, some people explicitly want incoherent, non-blocking access > which is going to trigger warnings by this patch but are probably better > served by explicit suppression. > > v2: Also mark the pointers as inaccessible following the explicit unmap > and implicit unmap upon return to the cache. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #2 from Pavel Ondračka 2012-02-11 03:59:26 UTC --- (In reply to comment #1) > I am sure the commit in question is not the cause. I prematurely added the > code for the new ioctl and disabled it later on, because my kernel code the > commit > was supposed to interact with wasn't accepted. > > The problem when bisecting is that now it tries to call a non-existing ioctl > if the DRM minor version is >=12, which makes some tests fail. Could you > please > check dmesg to see if that's the case? There should be some error messages > from DRM. None of the tests produce any output in dmesg. > > I think that some of those piglit failures are caused by the glsl-to-tgsi > translator. You can disable glsl-to-tgsi by commenting out: > > functions->LinkShader = st_link_shader; > > at the end of src/mesa/state_tracker/st_cb_program.c. From all the mentioned tests only glsl-fs-discard-02 pass when I disable glsl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand that if I don't have kernel with support for the new ioctl it breaks the tests, however if the ioctl was disabled later shouldn't be current git working unless another regression happened? > Anyway, sorry, I won't probably help you with this bug anytime soon. Well, I don't care much for piglit, I just want to make sure r300g don't get too rusty now when the development has moved to new drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #3 from Marek Olšák 2012-02-11 04:19:27 PST --- (In reply to comment #2) > (In reply to comment #1) > > I am sure the commit in question is not the cause. I prematurely added the > > code for the new ioctl and disabled it later on, because my kernel code the > > commit > > was supposed to interact with wasn't accepted. > > > > The problem when bisecting is that now it tries to call a non-existing > > ioctl if the DRM minor version is >=12, which makes some tests fail. Could > > you please > > check dmesg to see if that's the case? There should be some error messages > > from DRM. > > None of the tests produce any output in dmesg. Okay. > > > > I think that some of those piglit failures are caused by the glsl-to-tgsi > > translator. You can disable glsl-to-tgsi by commenting out: > > > > functions->LinkShader = st_link_shader; > > > > at the end of src/mesa/state_tracker/st_cb_program.c. > > From all the mentioned tests only glsl-fs-discard-02 pass when I disable > glsl-to-tgsi. > > BTW in which commit was the new ioctl disabled? In this one: ef64da8f013691c66744064769db379e57ef95de > I mean, I can understand that if I don't have kernel with support for the new > ioctl it breaks the tests, > however if the ioctl was disabled later shouldn't be current git working > unless another regression happened? Yes, it should. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #7 from Tomi Pieviläinen 2012-02-11 04:20:42 PST --- Sure, I'll see if I can find it on the repos. If not, might take a bit longer. The displayport is connected to an active dp-to-dldvi adapter, which is connected to Samsung SyncMaster 305tplus (monitor with only dldvi input, and accepts only 2560x1600 and 1280x800 modes). The dvi is connected to HP LP2475w, which is pivoted. The APU is A3500 connected to Asus F1A75V_PRO motherboard. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #8 from Tomi Pieviläinen 2012-02-11 04:28:58 PST --- Running now on 3.3rc3, same results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #4 from Pavel Ondračka 2012-02-11 04:51:23 PST --- OK, I can finally see whats going on. ef64da8f013691c66744064769db379e57ef95de fails however 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 + manually applied ef64da8f013691c66744064769db379e57ef95de pass. So indeed a second regression happened :-( Running second bisect right now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added CC||bryancain3+...@gmail.com --- Comment #5 from Pavel Ondračka 2012-02-11 05:59:42 PST --- Marek you were right with the glsl_to_tgsi cause. It indeed seems majority of the commits fails due to some glsl_to_tgsi changes. fs-any-bvec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if regressed with: a43f68810a347f3e952a0bc401be6edb91e1baea is the first bad commit commit a43f68810a347f3e952a0bc401be6edb91e1baea Author: Bryan Cain Date: Sat Aug 20 13:26:12 2011 -0500 glsl_to_tgsi: implement ir_unop_any using DP4 w/saturate or DP4 w/SLT This is a port of commit 92ca560d68e8 to glsl_to_tgsi, with integer support added. glsl1-inequality (vec2, pass) fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-vec2-vec2-using-if regressed with: f3dce133f0422c42ca61f07f488237107efc30e6 is the first bad commit commit f3dce133f0422c42ca61f07f488237107efc30e6 Author: Bryan Cain Date: Sat Aug 20 13:56:06 2011 -0500 glsl_to_tgsi: implement ir_binop_any_nequal using DP4 w/saturate or DP4 w/SLT Implement the any() part of the operation the same way regular ir_unop_any is implemented. This is a port of commit e7bf096e8b04 to glsl_to_tgsi, with added integer support. The rest of the tests (glsl-fs-discard-02, glsl-max-varyings and glsl-vs-loop-redundant-condition) regressed in another (probably 3 different) places. I'll get to them later. BTW this may be the worst bisect I've ever done. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regressions after glsl_to_tgsi changes
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added Summary|[r300g, bisected] Multiple |[r300g, bisected] Multiple |piglit regression after |piglit regressions after |winsys/radeon: hook up the |glsl_to_tgsi changes |new DRM_RADEON_GEM_WAIT | |ioctl | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #25 from Florian Mickler 2012-02-11 07:51:40 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit 304a48400d9718f74ec35ae46f30868a5f4c4516 Author: Alex Deucher Date: Thu Feb 2 10:18:00 2012 -0500 drm/radeon/kms: fix TRAVIS panel setup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45503] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
https://bugs.freedesktop.org/show_bug.cgi?id=45503 --- Comment #13 from Florian Mickler 2012-02-11 07:52:31 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit de47a9cd62771e3e78954d855d2304fbad4c5a44 Author: Dave Airlie Date: Thu Feb 2 15:25:16 2012 + drm/radeon: fix use after free in ATRM bios reading code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new
https://bugs.freedesktop.org/show_bug.cgi?id=45907 Alex Deucher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2012-02-11 07:58:31 PST --- fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c565ff60d6fce8c3402e60e6475c03717b297965 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38173] DXT3 and DXT5 broken on Cayman gpu
https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon 9250 pci
On Tue, 07 Feb 2012 19:01:04 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:41 +0100, acrux wrote: > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon 9250 PCI > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > Machine check in kernel mode. > > Data Write PLB Error > > Machine Check exception is imprecise > > Oops: Machine check, sig: 7 [#1] > > Canyonlands > > Modules linked in: > > NIP: c000a580 LR: c0399084 CTR: 000bfffb > > REGS: efff7f10 TRAP: 0214 Not tainted (3.3.0-rc2) > > MSR: 00029000 CR: 24714222 XER: > > TASK = ef83[1] 'swapper' THREAD: ef834000 > > GPR00: ef835c30 ef83 f550 0030 > > ef835bd8 GPR08: ef835b38 f5500014 000c0001 > > 24714284 8500682f ef8f7800 ef17c1c0 GPR16: 0020 c05f > > c06105de ef835d08 c0610351 c056a6f0 c0610600 GPR24: > > fff4 ef8ca47c ef9ffe00 ef9fff38 ef9e7c00 ef835cb8 ef8ea000 > > ef8ca400 NIP [c000a580] _memset_io+0x54/0x90 LR [c0399084] > > radeon_fb_find_or_create_single+0x234/0x42c Call Trace: > > [ef835c30] [c0399068] radeon_fb_find_or_create_single+0x218/0x42c > > (unreliable) > > Again looks like the problem occurs when first accessing VRAM, in this > case for clearing the visible framebuffer contents. > > I wonder if we're missing something to handle device memory access > properly on your machine(s)... Is ioremap_wc() working on them with > other drivers? > > i got a kernel panic also with the legacy radeon framebuffer -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Tue, 07 Feb 2012 18:32:44 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:38 +0100, acrux wrote: > > > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon X1650PRO PCIE > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > [drm] GART: num cpu pages 131072, num gpu pages 131072 > > The driver detects the CPU page size as 4K, is that correct? > > it's right, 4k page size Just a curiosity, i've only two powerpc machines[1] equipped with PCIE videocards and both them are not able to boot with radeonkms. Modern PCI-E videocards are not recognized by the old linux framebuffer subsystem and they solely can be managed by the new KMS frame buffer that doesn't work properly on Power Architecture. Anyway, YDL Powerstation can fallback to use the old OpenFirmware frame buffer. KMS porting to Power Architecture machines with PCIE is it only an exercise or someone is also able to test them? Because i can understand that the userbase is non-existent and the dri-developers don't have these "rare" machines. [1] YDL Powerstation, Acube Sam460ex cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45943] New: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Bug #: 45943 Summary: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Classification: Unclassified Product: Mesa Version: git Platform: Other URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi c/webgl/sdk/tests/webgl-conformance-tests.html OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz Created attachment 56904 --> https://bugs.freedesktop.org/attachment.cgi?id=56904 full backtrace Triggered with Firefox 10 at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html (click run tests and wait). Firefox 10 is needed earlier versions doesn't trigger this. radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. r300: Warning: cs_count off by -6 at (r300_emit_aa_state, r300_emit.c:370) radeon: The kernel rejected CS, see dmesg for more information. r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Program received signal SIGTRAP, Trace/breakpoint trap. _debug_assert_fail (expr=0x2c2fa6f "(aa->dest)->cs_buf", file=0x2c2fa58 "r300_emit.c", line= 365, function=0x2c2ff77 "r300_emit_aa_state") at util/u_debug.c:281 Full backtrace attached, from dmesg: [50370.978205] [drm:r100_cs_packet_next_reloc] *ERROR* No packet3 for relocation for packet at 13. [50370.978211] [drm] ib[13]=0x13A1 [50370.978214] [drm] ib[14]=0x00C30040 [50370.978217] [drm:r300_packet0_check] *ERROR* No reloc for ib[12]=0x4E80 [50370.978220] [drm] ib[11]=0x13A0 [50370.978223] [drm] ib[12]=0x [50370.978225] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! GPU:RV530 Kernel: 3.2.3 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee Libdrm: 2.4.31 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #2 from lschin...@gmail.com 2012-02-11 16:37:42 UTC --- The workaround work ok -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Bug #: 45921 Summary: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com Found while comparing piglit results between 7.11 and 8.0 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 is the first bad commit commit 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 Author: Marek Olšák Date: Sun Aug 7 19:04:37 2011 +0200 winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Reviewed-by: Alex Deucher Regressed tests: glsl1-inequality (vec2, pass) glsl-fs-discard-02 glsl-max-varyings glsl-vs-loop-redundant-condition fs-any-bvec2-using-if fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-vec2-vec2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if and probably some others All those tests pass on 7.11 and fail in both 8.0 and master branch. GPU: RV530 Kernel: 3.2.3 Libdrm: 2.4.31 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45901] [r300g, bisected] vs-atan-float-float fail
https://bugs.freedesktop.org/show_bug.cgi?id=45901 --- Comment #1 from Pavel Ondračka 2012-02-11 03:11:30 UTC --- glsl-vs-vec4-indexing-temp-dst-in-loop is another test regressed by aforementioned commit. BTW both tests pass with llvmpipe and softpipe, so this is probably just some uncovered r300 compiler bug, not a real regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #1 from Marek Olšák 2012-02-11 03:21:46 PST --- I am sure the commit in question is not the cause. I prematurely added the code for the new ioctl and disabled it later on, because my kernel code the commit was supposed to interact with wasn't accepted. The problem when bisecting is that now it tries to call a non-existing ioctl if the DRM minor version is >=12, which makes some tests fail. Could you please check dmesg to see if that's the case? There should be some error messages from DRM. I think that some of those piglit failures are caused by the glsl-to-tgsi translator. You can disable glsl-to-tgsi by commenting out: functions->LinkShader = st_link_shader; at the end of src/mesa/state_tracker/st_cb_program.c. Anyway, sorry, I won't probably help you with this bug anytime soon. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). Signed-off-by: Yufeng Shen --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_i2c.c | 23 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 559fb6f..4ed9fd9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -722,6 +722,8 @@ typedef struct drm_i915_private { u8 corr; spinlock_t *mchdev_lock; + struct mutex gmbus_mutex; + enum no_fbc_reason no_fbc_reason; struct drm_mm_node *compressed_fb; diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index d98cee6..42569b1 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct intel_gmbus, adapter); struct drm_i915_private *dev_priv = adapter->algo_data; - int i, reg_offset; + int i, reg_offset, ret; - if (bus->force_bit) - return intel_i2c_quirk_xfer(dev_priv, + mutex_lock(&dev_priv->gmbus_mutex); + + if (bus->force_bit) { + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); + goto out; + } reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0; @@ -320,7 +324,8 @@ done: * start of the next xfer, till then let it sleep. */ I915_WRITE(GMBUS0 + reg_offset, 0); - return i; + ret = i; + goto out; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", @@ -330,9 +335,13 @@ timeout: /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) - return -ENOMEM; + ret = -ENOMEM; + else + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); +out: + mutex_unlock(&dev_priv->gmbus_mutex); + return ret; } static u32 gmbus_func(struct i2c_adapter *adapter) @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev) if (dev_priv->gmbus == NULL) return -ENOMEM; + mutex_init(&dev_priv->gmbus_mutex); + for (i = 0; i < GMBUS_NUM_PORTS; i++) { struct intel_gmbus *bus = &dev_priv->gmbus[i]; -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Detect cache domain inconsistency with valgrind
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson --- intel/intel_bufmgr_gem.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 2e65580..3856d3d 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -922,6 +922,20 @@ drm_intel_gem_bo_free(drm_intel_bo *bo) free(bo); } +static void +drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo) +{ +#if HAVE_VALGRIND + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; + + if (bo_gem->mem_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_virtual, bo->size); + + if (bo_gem->gtt_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size); +#endif +} + /** Frees all cached buffers significantly older than @time. */ static void drm_intel_gem_cleanup_bo_cache(drm_intel_bufmgr_gem *bufmgr_gem, time_t time) @@ -1050,6 +1064,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time) DBG("bo freed with non-zero map-count %d\n", bo_gem->map_count); bo_gem->map_count = 0; drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); } DRMLISTDEL(&bo_gem->name_list); @@ -1160,6 +1175,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) if (write_enable) bo_gem->mapped_cpu_write = true; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->mem_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1240,6 +1257,8 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) strerror(errno)); } + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1289,6 +1308,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) */ if (--bo_gem->map_count == 0) { drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); bo->virtual = NULL; } pthread_mutex_unlock(&bufmgr_gem->lock); @@ -1615,6 +1635,8 @@ drm_intel_gem_bo_process_reloc(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc(target_bo); @@ -1639,6 +1661,8 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc2(target_bo); -- 1.7.9 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote: > Every access to either the GTT or CPU pointer is supposed to be > proceeded by a set_domain ioctl so that GEM is able to manage the cache > domains correctly and for the following access to be coherent. Of > course, some people explicitly want incoherent, non-blocking access > which is going to trigger warnings by this patch but are probably better > served by explicit suppression. > > v2: Also mark the pointers as inaccessible following the explicit unmap > and implicit unmap upon return to the cache. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #2 from Pavel Ondračka 2012-02-11 03:59:26 UTC --- (In reply to comment #1) > I am sure the commit in question is not the cause. I prematurely added the > code for the new ioctl and disabled it later on, because my kernel code the > commit > was supposed to interact with wasn't accepted. > > The problem when bisecting is that now it tries to call a non-existing ioctl > if the DRM minor version is >=12, which makes some tests fail. Could you > please > check dmesg to see if that's the case? There should be some error messages > from DRM. None of the tests produce any output in dmesg. > > I think that some of those piglit failures are caused by the glsl-to-tgsi > translator. You can disable glsl-to-tgsi by commenting out: > > functions->LinkShader = st_link_shader; > > at the end of src/mesa/state_tracker/st_cb_program.c. From all the mentioned tests only glsl-fs-discard-02 pass when I disable glsl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand that if I don't have kernel with support for the new ioctl it breaks the tests, however if the ioctl was disabled later shouldn't be current git working unless another regression happened? > Anyway, sorry, I won't probably help you with this bug anytime soon. Well, I don't care much for piglit, I just want to make sure r300g don't get too rusty now when the development has moved to new drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #3 from Marek Olšák 2012-02-11 04:19:27 PST --- (In reply to comment #2) > (In reply to comment #1) > > I am sure the commit in question is not the cause. I prematurely added the > > code for the new ioctl and disabled it later on, because my kernel code the > > commit > > was supposed to interact with wasn't accepted. > > > > The problem when bisecting is that now it tries to call a non-existing > > ioctl if the DRM minor version is >=12, which makes some tests fail. Could > > you please > > check dmesg to see if that's the case? There should be some error messages > > from DRM. > > None of the tests produce any output in dmesg. Okay. > > > > I think that some of those piglit failures are caused by the glsl-to-tgsi > > translator. You can disable glsl-to-tgsi by commenting out: > > > > functions->LinkShader = st_link_shader; > > > > at the end of src/mesa/state_tracker/st_cb_program.c. > > From all the mentioned tests only glsl-fs-discard-02 pass when I disable > glsl-to-tgsi. > > BTW in which commit was the new ioctl disabled? In this one: ef64da8f013691c66744064769db379e57ef95de > I mean, I can understand that if I don't have kernel with support for the new > ioctl it breaks the tests, > however if the ioctl was disabled later shouldn't be current git working > unless another regression happened? Yes, it should. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #7 from Tomi Pieviläinen 2012-02-11 04:20:42 PST --- Sure, I'll see if I can find it on the repos. If not, might take a bit longer. The displayport is connected to an active dp-to-dldvi adapter, which is connected to Samsung SyncMaster 305tplus (monitor with only dldvi input, and accepts only 2560x1600 and 1280x800 modes). The dvi is connected to HP LP2475w, which is pivoted. The APU is A3500 connected to Asus F1A75V_PRO motherboard. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #8 from Tomi Pieviläinen 2012-02-11 04:28:58 PST --- Running now on 3.3rc3, same results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #4 from Pavel Ondračka 2012-02-11 04:51:23 PST --- OK, I can finally see whats going on. ef64da8f013691c66744064769db379e57ef95de fails however 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 + manually applied ef64da8f013691c66744064769db379e57ef95de pass. So indeed a second regression happened :-( Running second bisect right now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added CC||bryancain3+...@gmail.com --- Comment #5 from Pavel Ondračka 2012-02-11 05:59:42 PST --- Marek you were right with the glsl_to_tgsi cause. It indeed seems majority of the commits fails due to some glsl_to_tgsi changes. fs-any-bvec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if regressed with: a43f68810a347f3e952a0bc401be6edb91e1baea is the first bad commit commit a43f68810a347f3e952a0bc401be6edb91e1baea Author: Bryan Cain Date: Sat Aug 20 13:26:12 2011 -0500 glsl_to_tgsi: implement ir_unop_any using DP4 w/saturate or DP4 w/SLT This is a port of commit 92ca560d68e8 to glsl_to_tgsi, with integer support added. glsl1-inequality (vec2, pass) fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-vec2-vec2-using-if regressed with: f3dce133f0422c42ca61f07f488237107efc30e6 is the first bad commit commit f3dce133f0422c42ca61f07f488237107efc30e6 Author: Bryan Cain Date: Sat Aug 20 13:56:06 2011 -0500 glsl_to_tgsi: implement ir_binop_any_nequal using DP4 w/saturate or DP4 w/SLT Implement the any() part of the operation the same way regular ir_unop_any is implemented. This is a port of commit e7bf096e8b04 to glsl_to_tgsi, with added integer support. The rest of the tests (glsl-fs-discard-02, glsl-max-varyings and glsl-vs-loop-redundant-condition) regressed in another (probably 3 different) places. I'll get to them later. BTW this may be the worst bisect I've ever done. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regressions after glsl_to_tgsi changes
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added Summary|[r300g, bisected] Multiple |[r300g, bisected] Multiple |piglit regression after |piglit regressions after |winsys/radeon: hook up the |glsl_to_tgsi changes |new DRM_RADEON_GEM_WAIT | |ioctl | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #25 from Florian Mickler 2012-02-11 07:51:40 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit 304a48400d9718f74ec35ae46f30868a5f4c4516 Author: Alex Deucher Date: Thu Feb 2 10:18:00 2012 -0500 drm/radeon/kms: fix TRAVIS panel setup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45503] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
https://bugs.freedesktop.org/show_bug.cgi?id=45503 --- Comment #13 from Florian Mickler 2012-02-11 07:52:31 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit de47a9cd62771e3e78954d855d2304fbad4c5a44 Author: Dave Airlie Date: Thu Feb 2 15:25:16 2012 + drm/radeon: fix use after free in ATRM bios reading code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new
https://bugs.freedesktop.org/show_bug.cgi?id=45907 Alex Deucher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2012-02-11 07:58:31 PST --- fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c565ff60d6fce8c3402e60e6475c03717b297965 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38173] DXT3 and DXT5 broken on Cayman gpu
https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon 9250 pci
On Tue, 07 Feb 2012 19:01:04 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:41 +0100, acrux wrote: > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon 9250 PCI > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > Machine check in kernel mode. > > Data Write PLB Error > > Machine Check exception is imprecise > > Oops: Machine check, sig: 7 [#1] > > Canyonlands > > Modules linked in: > > NIP: c000a580 LR: c0399084 CTR: 000bfffb > > REGS: efff7f10 TRAP: 0214 Not tainted (3.3.0-rc2) > > MSR: 00029000 CR: 24714222 XER: > > TASK = ef83[1] 'swapper' THREAD: ef834000 > > GPR00: ef835c30 ef83 f550 0030 > > ef835bd8 GPR08: ef835b38 f5500014 000c0001 > > 24714284 8500682f ef8f7800 ef17c1c0 GPR16: 0020 c05f > > c06105de ef835d08 c0610351 c056a6f0 c0610600 GPR24: > > fff4 ef8ca47c ef9ffe00 ef9fff38 ef9e7c00 ef835cb8 ef8ea000 > > ef8ca400 NIP [c000a580] _memset_io+0x54/0x90 LR [c0399084] > > radeon_fb_find_or_create_single+0x234/0x42c Call Trace: > > [ef835c30] [c0399068] radeon_fb_find_or_create_single+0x218/0x42c > > (unreliable) > > Again looks like the problem occurs when first accessing VRAM, in this > case for clearing the visible framebuffer contents. > > I wonder if we're missing something to handle device memory access > properly on your machine(s)... Is ioremap_wc() working on them with > other drivers? > > i got a kernel panic also with the legacy radeon framebuffer -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Tue, 07 Feb 2012 18:32:44 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:38 +0100, acrux wrote: > > > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon X1650PRO PCIE > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > [drm] GART: num cpu pages 131072, num gpu pages 131072 > > The driver detects the CPU page size as 4K, is that correct? > > it's right, 4k page size Just a curiosity, i've only two powerpc machines[1] equipped with PCIE videocards and both them are not able to boot with radeonkms. Modern PCI-E videocards are not recognized by the old linux framebuffer subsystem and they solely can be managed by the new KMS frame buffer that doesn't work properly on Power Architecture. Anyway, YDL Powerstation can fallback to use the old OpenFirmware frame buffer. KMS porting to Power Architecture machines with PCIE is it only an exercise or someone is also able to test them? Because i can understand that the userbase is non-existent and the dri-developers don't have these "rare" machines. [1] YDL Powerstation, Acube Sam460ex cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45943] New: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Bug #: 45943 Summary: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Classification: Unclassified Product: Mesa Version: git Platform: Other URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi c/webgl/sdk/tests/webgl-conformance-tests.html OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz Created attachment 56904 --> https://bugs.freedesktop.org/attachment.cgi?id=56904 full backtrace Triggered with Firefox 10 at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html (click run tests and wait). Firefox 10 is needed earlier versions doesn't trigger this. radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. r300: Warning: cs_count off by -6 at (r300_emit_aa_state, r300_emit.c:370) radeon: The kernel rejected CS, see dmesg for more information. r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Program received signal SIGTRAP, Trace/breakpoint trap. _debug_assert_fail (expr=0x2c2fa6f "(aa->dest)->cs_buf", file=0x2c2fa58 "r300_emit.c", line= 365, function=0x2c2ff77 "r300_emit_aa_state") at util/u_debug.c:281 Full backtrace attached, from dmesg: [50370.978205] [drm:r100_cs_packet_next_reloc] *ERROR* No packet3 for relocation for packet at 13. [50370.978211] [drm] ib[13]=0x13A1 [50370.978214] [drm] ib[14]=0x00C30040 [50370.978217] [drm:r300_packet0_check] *ERROR* No reloc for ib[12]=0x4E80 [50370.978220] [drm] ib[11]=0x13A0 [50370.978223] [drm] ib[12]=0x [50370.978225] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! GPU:RV530 Kernel: 3.2.3 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee Libdrm: 2.4.31 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #2 from lschin...@gmail.com 2012-02-11 16:37:42 UTC --- The workaround work ok -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Bug #: 45921 Summary: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com Found while comparing piglit results between 7.11 and 8.0 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 is the first bad commit commit 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 Author: Marek Olšák Date: Sun Aug 7 19:04:37 2011 +0200 winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Reviewed-by: Alex Deucher Regressed tests: glsl1-inequality (vec2, pass) glsl-fs-discard-02 glsl-max-varyings glsl-vs-loop-redundant-condition fs-any-bvec2-using-if fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-vec2-vec2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if and probably some others All those tests pass on 7.11 and fail in both 8.0 and master branch. GPU: RV530 Kernel: 3.2.3 Libdrm: 2.4.31 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45901] [r300g, bisected] vs-atan-float-float fail
https://bugs.freedesktop.org/show_bug.cgi?id=45901 --- Comment #1 from Pavel Ondračka 2012-02-11 03:11:30 UTC --- glsl-vs-vec4-indexing-temp-dst-in-loop is another test regressed by aforementioned commit. BTW both tests pass with llvmpipe and softpipe, so this is probably just some uncovered r300 compiler bug, not a real regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #1 from Marek Olšák 2012-02-11 03:21:46 PST --- I am sure the commit in question is not the cause. I prematurely added the code for the new ioctl and disabled it later on, because my kernel code the commit was supposed to interact with wasn't accepted. The problem when bisecting is that now it tries to call a non-existing ioctl if the DRM minor version is >=12, which makes some tests fail. Could you please check dmesg to see if that's the case? There should be some error messages from DRM. I think that some of those piglit failures are caused by the glsl-to-tgsi translator. You can disable glsl-to-tgsi by commenting out: functions->LinkShader = st_link_shader; at the end of src/mesa/state_tracker/st_cb_program.c. Anyway, sorry, I won't probably help you with this bug anytime soon. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). Signed-off-by: Yufeng Shen --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_i2c.c | 23 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 559fb6f..4ed9fd9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -722,6 +722,8 @@ typedef struct drm_i915_private { u8 corr; spinlock_t *mchdev_lock; + struct mutex gmbus_mutex; + enum no_fbc_reason no_fbc_reason; struct drm_mm_node *compressed_fb; diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index d98cee6..42569b1 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct intel_gmbus, adapter); struct drm_i915_private *dev_priv = adapter->algo_data; - int i, reg_offset; + int i, reg_offset, ret; - if (bus->force_bit) - return intel_i2c_quirk_xfer(dev_priv, + mutex_lock(&dev_priv->gmbus_mutex); + + if (bus->force_bit) { + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); + goto out; + } reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0; @@ -320,7 +324,8 @@ done: * start of the next xfer, till then let it sleep. */ I915_WRITE(GMBUS0 + reg_offset, 0); - return i; + ret = i; + goto out; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", @@ -330,9 +335,13 @@ timeout: /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) - return -ENOMEM; + ret = -ENOMEM; + else + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); +out: + mutex_unlock(&dev_priv->gmbus_mutex); + return ret; } static u32 gmbus_func(struct i2c_adapter *adapter) @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev) if (dev_priv->gmbus == NULL) return -ENOMEM; + mutex_init(&dev_priv->gmbus_mutex); + for (i = 0; i < GMBUS_NUM_PORTS; i++) { struct intel_gmbus *bus = &dev_priv->gmbus[i]; -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Detect cache domain inconsistency with valgrind
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson --- intel/intel_bufmgr_gem.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 2e65580..3856d3d 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -922,6 +922,20 @@ drm_intel_gem_bo_free(drm_intel_bo *bo) free(bo); } +static void +drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo) +{ +#if HAVE_VALGRIND + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; + + if (bo_gem->mem_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_virtual, bo->size); + + if (bo_gem->gtt_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size); +#endif +} + /** Frees all cached buffers significantly older than @time. */ static void drm_intel_gem_cleanup_bo_cache(drm_intel_bufmgr_gem *bufmgr_gem, time_t time) @@ -1050,6 +1064,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time) DBG("bo freed with non-zero map-count %d\n", bo_gem->map_count); bo_gem->map_count = 0; drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); } DRMLISTDEL(&bo_gem->name_list); @@ -1160,6 +1175,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) if (write_enable) bo_gem->mapped_cpu_write = true; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->mem_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1240,6 +1257,8 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) strerror(errno)); } + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1289,6 +1308,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) */ if (--bo_gem->map_count == 0) { drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); bo->virtual = NULL; } pthread_mutex_unlock(&bufmgr_gem->lock); @@ -1615,6 +1635,8 @@ drm_intel_gem_bo_process_reloc(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc(target_bo); @@ -1639,6 +1661,8 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc2(target_bo); -- 1.7.9 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote: > Every access to either the GTT or CPU pointer is supposed to be > proceeded by a set_domain ioctl so that GEM is able to manage the cache > domains correctly and for the following access to be coherent. Of > course, some people explicitly want incoherent, non-blocking access > which is going to trigger warnings by this patch but are probably better > served by explicit suppression. > > v2: Also mark the pointers as inaccessible following the explicit unmap > and implicit unmap upon return to the cache. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #2 from Pavel Ondračka 2012-02-11 03:59:26 UTC --- (In reply to comment #1) > I am sure the commit in question is not the cause. I prematurely added the > code for the new ioctl and disabled it later on, because my kernel code the > commit > was supposed to interact with wasn't accepted. > > The problem when bisecting is that now it tries to call a non-existing ioctl > if the DRM minor version is >=12, which makes some tests fail. Could you > please > check dmesg to see if that's the case? There should be some error messages > from DRM. None of the tests produce any output in dmesg. > > I think that some of those piglit failures are caused by the glsl-to-tgsi > translator. You can disable glsl-to-tgsi by commenting out: > > functions->LinkShader = st_link_shader; > > at the end of src/mesa/state_tracker/st_cb_program.c. From all the mentioned tests only glsl-fs-discard-02 pass when I disable glsl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand that if I don't have kernel with support for the new ioctl it breaks the tests, however if the ioctl was disabled later shouldn't be current git working unless another regression happened? > Anyway, sorry, I won't probably help you with this bug anytime soon. Well, I don't care much for piglit, I just want to make sure r300g don't get too rusty now when the development has moved to new drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #3 from Marek Olšák 2012-02-11 04:19:27 PST --- (In reply to comment #2) > (In reply to comment #1) > > I am sure the commit in question is not the cause. I prematurely added the > > code for the new ioctl and disabled it later on, because my kernel code the > > commit > > was supposed to interact with wasn't accepted. > > > > The problem when bisecting is that now it tries to call a non-existing > > ioctl if the DRM minor version is >=12, which makes some tests fail. Could > > you please > > check dmesg to see if that's the case? There should be some error messages > > from DRM. > > None of the tests produce any output in dmesg. Okay. > > > > I think that some of those piglit failures are caused by the glsl-to-tgsi > > translator. You can disable glsl-to-tgsi by commenting out: > > > > functions->LinkShader = st_link_shader; > > > > at the end of src/mesa/state_tracker/st_cb_program.c. > > From all the mentioned tests only glsl-fs-discard-02 pass when I disable > glsl-to-tgsi. > > BTW in which commit was the new ioctl disabled? In this one: ef64da8f013691c66744064769db379e57ef95de > I mean, I can understand that if I don't have kernel with support for the new > ioctl it breaks the tests, > however if the ioctl was disabled later shouldn't be current git working > unless another regression happened? Yes, it should. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #7 from Tomi Pieviläinen 2012-02-11 04:20:42 PST --- Sure, I'll see if I can find it on the repos. If not, might take a bit longer. The displayport is connected to an active dp-to-dldvi adapter, which is connected to Samsung SyncMaster 305tplus (monitor with only dldvi input, and accepts only 2560x1600 and 1280x800 modes). The dvi is connected to HP LP2475w, which is pivoted. The APU is A3500 connected to Asus F1A75V_PRO motherboard. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #8 from Tomi Pieviläinen 2012-02-11 04:28:58 PST --- Running now on 3.3rc3, same results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #4 from Pavel Ondračka 2012-02-11 04:51:23 PST --- OK, I can finally see whats going on. ef64da8f013691c66744064769db379e57ef95de fails however 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 + manually applied ef64da8f013691c66744064769db379e57ef95de pass. So indeed a second regression happened :-( Running second bisect right now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added CC||bryancain3+...@gmail.com --- Comment #5 from Pavel Ondračka 2012-02-11 05:59:42 PST --- Marek you were right with the glsl_to_tgsi cause. It indeed seems majority of the commits fails due to some glsl_to_tgsi changes. fs-any-bvec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if regressed with: a43f68810a347f3e952a0bc401be6edb91e1baea is the first bad commit commit a43f68810a347f3e952a0bc401be6edb91e1baea Author: Bryan Cain Date: Sat Aug 20 13:26:12 2011 -0500 glsl_to_tgsi: implement ir_unop_any using DP4 w/saturate or DP4 w/SLT This is a port of commit 92ca560d68e8 to glsl_to_tgsi, with integer support added. glsl1-inequality (vec2, pass) fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-vec2-vec2-using-if regressed with: f3dce133f0422c42ca61f07f488237107efc30e6 is the first bad commit commit f3dce133f0422c42ca61f07f488237107efc30e6 Author: Bryan Cain Date: Sat Aug 20 13:56:06 2011 -0500 glsl_to_tgsi: implement ir_binop_any_nequal using DP4 w/saturate or DP4 w/SLT Implement the any() part of the operation the same way regular ir_unop_any is implemented. This is a port of commit e7bf096e8b04 to glsl_to_tgsi, with added integer support. The rest of the tests (glsl-fs-discard-02, glsl-max-varyings and glsl-vs-loop-redundant-condition) regressed in another (probably 3 different) places. I'll get to them later. BTW this may be the worst bisect I've ever done. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regressions after glsl_to_tgsi changes
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added Summary|[r300g, bisected] Multiple |[r300g, bisected] Multiple |piglit regression after |piglit regressions after |winsys/radeon: hook up the |glsl_to_tgsi changes |new DRM_RADEON_GEM_WAIT | |ioctl | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #25 from Florian Mickler 2012-02-11 07:51:40 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit 304a48400d9718f74ec35ae46f30868a5f4c4516 Author: Alex Deucher Date: Thu Feb 2 10:18:00 2012 -0500 drm/radeon/kms: fix TRAVIS panel setup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45503] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
https://bugs.freedesktop.org/show_bug.cgi?id=45503 --- Comment #13 from Florian Mickler 2012-02-11 07:52:31 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit de47a9cd62771e3e78954d855d2304fbad4c5a44 Author: Dave Airlie Date: Thu Feb 2 15:25:16 2012 + drm/radeon: fix use after free in ATRM bios reading code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new
https://bugs.freedesktop.org/show_bug.cgi?id=45907 Alex Deucher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2012-02-11 07:58:31 PST --- fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c565ff60d6fce8c3402e60e6475c03717b297965 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38173] DXT3 and DXT5 broken on Cayman gpu
https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon 9250 pci
On Tue, 07 Feb 2012 19:01:04 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:41 +0100, acrux wrote: > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon 9250 PCI > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > Machine check in kernel mode. > > Data Write PLB Error > > Machine Check exception is imprecise > > Oops: Machine check, sig: 7 [#1] > > Canyonlands > > Modules linked in: > > NIP: c000a580 LR: c0399084 CTR: 000bfffb > > REGS: efff7f10 TRAP: 0214 Not tainted (3.3.0-rc2) > > MSR: 00029000 CR: 24714222 XER: > > TASK = ef83[1] 'swapper' THREAD: ef834000 > > GPR00: ef835c30 ef83 f550 0030 > > ef835bd8 GPR08: ef835b38 f5500014 000c0001 > > 24714284 8500682f ef8f7800 ef17c1c0 GPR16: 0020 c05f > > c06105de ef835d08 c0610351 c056a6f0 c0610600 GPR24: > > fff4 ef8ca47c ef9ffe00 ef9fff38 ef9e7c00 ef835cb8 ef8ea000 > > ef8ca400 NIP [c000a580] _memset_io+0x54/0x90 LR [c0399084] > > radeon_fb_find_or_create_single+0x234/0x42c Call Trace: > > [ef835c30] [c0399068] radeon_fb_find_or_create_single+0x218/0x42c > > (unreliable) > > Again looks like the problem occurs when first accessing VRAM, in this > case for clearing the visible framebuffer contents. > > I wonder if we're missing something to handle device memory access > properly on your machine(s)... Is ioremap_wc() working on them with > other drivers? > > i got a kernel panic also with the legacy radeon framebuffer -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Tue, 07 Feb 2012 18:32:44 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:38 +0100, acrux wrote: > > > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon X1650PRO PCIE > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > [drm] GART: num cpu pages 131072, num gpu pages 131072 > > The driver detects the CPU page size as 4K, is that correct? > > it's right, 4k page size Just a curiosity, i've only two powerpc machines[1] equipped with PCIE videocards and both them are not able to boot with radeonkms. Modern PCI-E videocards are not recognized by the old linux framebuffer subsystem and they solely can be managed by the new KMS frame buffer that doesn't work properly on Power Architecture. Anyway, YDL Powerstation can fallback to use the old OpenFirmware frame buffer. KMS porting to Power Architecture machines with PCIE is it only an exercise or someone is also able to test them? Because i can understand that the userbase is non-existent and the dri-developers don't have these "rare" machines. [1] YDL Powerstation, Acube Sam460ex cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45943] New: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Bug #: 45943 Summary: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Classification: Unclassified Product: Mesa Version: git Platform: Other URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi c/webgl/sdk/tests/webgl-conformance-tests.html OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz Created attachment 56904 --> https://bugs.freedesktop.org/attachment.cgi?id=56904 full backtrace Triggered with Firefox 10 at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html (click run tests and wait). Firefox 10 is needed earlier versions doesn't trigger this. radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. r300: Warning: cs_count off by -6 at (r300_emit_aa_state, r300_emit.c:370) radeon: The kernel rejected CS, see dmesg for more information. r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Program received signal SIGTRAP, Trace/breakpoint trap. _debug_assert_fail (expr=0x2c2fa6f "(aa->dest)->cs_buf", file=0x2c2fa58 "r300_emit.c", line= 365, function=0x2c2ff77 "r300_emit_aa_state") at util/u_debug.c:281 Full backtrace attached, from dmesg: [50370.978205] [drm:r100_cs_packet_next_reloc] *ERROR* No packet3 for relocation for packet at 13. [50370.978211] [drm] ib[13]=0x13A1 [50370.978214] [drm] ib[14]=0x00C30040 [50370.978217] [drm:r300_packet0_check] *ERROR* No reloc for ib[12]=0x4E80 [50370.978220] [drm] ib[11]=0x13A0 [50370.978223] [drm] ib[12]=0x [50370.978225] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! GPU:RV530 Kernel: 3.2.3 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee Libdrm: 2.4.31 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #2 from lschin...@gmail.com 2012-02-11 16:37:42 UTC --- The workaround work ok -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Bug #: 45921 Summary: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com Found while comparing piglit results between 7.11 and 8.0 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 is the first bad commit commit 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 Author: Marek Olšák Date: Sun Aug 7 19:04:37 2011 +0200 winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Reviewed-by: Alex Deucher Regressed tests: glsl1-inequality (vec2, pass) glsl-fs-discard-02 glsl-max-varyings glsl-vs-loop-redundant-condition fs-any-bvec2-using-if fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-vec2-vec2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if and probably some others All those tests pass on 7.11 and fail in both 8.0 and master branch. GPU: RV530 Kernel: 3.2.3 Libdrm: 2.4.31 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45901] [r300g, bisected] vs-atan-float-float fail
https://bugs.freedesktop.org/show_bug.cgi?id=45901 --- Comment #1 from Pavel Ondračka 2012-02-11 03:11:30 UTC --- glsl-vs-vec4-indexing-temp-dst-in-loop is another test regressed by aforementioned commit. BTW both tests pass with llvmpipe and softpipe, so this is probably just some uncovered r300 compiler bug, not a real regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #1 from Marek Olšák 2012-02-11 03:21:46 PST --- I am sure the commit in question is not the cause. I prematurely added the code for the new ioctl and disabled it later on, because my kernel code the commit was supposed to interact with wasn't accepted. The problem when bisecting is that now it tries to call a non-existing ioctl if the DRM minor version is >=12, which makes some tests fail. Could you please check dmesg to see if that's the case? There should be some error messages from DRM. I think that some of those piglit failures are caused by the glsl-to-tgsi translator. You can disable glsl-to-tgsi by commenting out: functions->LinkShader = st_link_shader; at the end of src/mesa/state_tracker/st_cb_program.c. Anyway, sorry, I won't probably help you with this bug anytime soon. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). Signed-off-by: Yufeng Shen --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_i2c.c | 23 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 559fb6f..4ed9fd9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -722,6 +722,8 @@ typedef struct drm_i915_private { u8 corr; spinlock_t *mchdev_lock; + struct mutex gmbus_mutex; + enum no_fbc_reason no_fbc_reason; struct drm_mm_node *compressed_fb; diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index d98cee6..42569b1 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct intel_gmbus, adapter); struct drm_i915_private *dev_priv = adapter->algo_data; - int i, reg_offset; + int i, reg_offset, ret; - if (bus->force_bit) - return intel_i2c_quirk_xfer(dev_priv, + mutex_lock(&dev_priv->gmbus_mutex); + + if (bus->force_bit) { + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); + goto out; + } reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0; @@ -320,7 +324,8 @@ done: * start of the next xfer, till then let it sleep. */ I915_WRITE(GMBUS0 + reg_offset, 0); - return i; + ret = i; + goto out; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", @@ -330,9 +335,13 @@ timeout: /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) - return -ENOMEM; + ret = -ENOMEM; + else + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); +out: + mutex_unlock(&dev_priv->gmbus_mutex); + return ret; } static u32 gmbus_func(struct i2c_adapter *adapter) @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev) if (dev_priv->gmbus == NULL) return -ENOMEM; + mutex_init(&dev_priv->gmbus_mutex); + for (i = 0; i < GMBUS_NUM_PORTS; i++) { struct intel_gmbus *bus = &dev_priv->gmbus[i]; -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Detect cache domain inconsistency with valgrind
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson --- intel/intel_bufmgr_gem.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 2e65580..3856d3d 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -922,6 +922,20 @@ drm_intel_gem_bo_free(drm_intel_bo *bo) free(bo); } +static void +drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo) +{ +#if HAVE_VALGRIND + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; + + if (bo_gem->mem_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_virtual, bo->size); + + if (bo_gem->gtt_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size); +#endif +} + /** Frees all cached buffers significantly older than @time. */ static void drm_intel_gem_cleanup_bo_cache(drm_intel_bufmgr_gem *bufmgr_gem, time_t time) @@ -1050,6 +1064,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time) DBG("bo freed with non-zero map-count %d\n", bo_gem->map_count); bo_gem->map_count = 0; drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); } DRMLISTDEL(&bo_gem->name_list); @@ -1160,6 +1175,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) if (write_enable) bo_gem->mapped_cpu_write = true; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->mem_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1240,6 +1257,8 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) strerror(errno)); } + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1289,6 +1308,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) */ if (--bo_gem->map_count == 0) { drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); bo->virtual = NULL; } pthread_mutex_unlock(&bufmgr_gem->lock); @@ -1615,6 +1635,8 @@ drm_intel_gem_bo_process_reloc(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc(target_bo); @@ -1639,6 +1661,8 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc2(target_bo); -- 1.7.9 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote: > Every access to either the GTT or CPU pointer is supposed to be > proceeded by a set_domain ioctl so that GEM is able to manage the cache > domains correctly and for the following access to be coherent. Of > course, some people explicitly want incoherent, non-blocking access > which is going to trigger warnings by this patch but are probably better > served by explicit suppression. > > v2: Also mark the pointers as inaccessible following the explicit unmap > and implicit unmap upon return to the cache. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #2 from Pavel Ondračka 2012-02-11 03:59:26 UTC --- (In reply to comment #1) > I am sure the commit in question is not the cause. I prematurely added the > code for the new ioctl and disabled it later on, because my kernel code the > commit > was supposed to interact with wasn't accepted. > > The problem when bisecting is that now it tries to call a non-existing ioctl > if the DRM minor version is >=12, which makes some tests fail. Could you > please > check dmesg to see if that's the case? There should be some error messages > from DRM. None of the tests produce any output in dmesg. > > I think that some of those piglit failures are caused by the glsl-to-tgsi > translator. You can disable glsl-to-tgsi by commenting out: > > functions->LinkShader = st_link_shader; > > at the end of src/mesa/state_tracker/st_cb_program.c. From all the mentioned tests only glsl-fs-discard-02 pass when I disable glsl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand that if I don't have kernel with support for the new ioctl it breaks the tests, however if the ioctl was disabled later shouldn't be current git working unless another regression happened? > Anyway, sorry, I won't probably help you with this bug anytime soon. Well, I don't care much for piglit, I just want to make sure r300g don't get too rusty now when the development has moved to new drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #3 from Marek Olšák 2012-02-11 04:19:27 PST --- (In reply to comment #2) > (In reply to comment #1) > > I am sure the commit in question is not the cause. I prematurely added the > > code for the new ioctl and disabled it later on, because my kernel code the > > commit > > was supposed to interact with wasn't accepted. > > > > The problem when bisecting is that now it tries to call a non-existing > > ioctl if the DRM minor version is >=12, which makes some tests fail. Could > > you please > > check dmesg to see if that's the case? There should be some error messages > > from DRM. > > None of the tests produce any output in dmesg. Okay. > > > > I think that some of those piglit failures are caused by the glsl-to-tgsi > > translator. You can disable glsl-to-tgsi by commenting out: > > > > functions->LinkShader = st_link_shader; > > > > at the end of src/mesa/state_tracker/st_cb_program.c. > > From all the mentioned tests only glsl-fs-discard-02 pass when I disable > glsl-to-tgsi. > > BTW in which commit was the new ioctl disabled? In this one: ef64da8f013691c66744064769db379e57ef95de > I mean, I can understand that if I don't have kernel with support for the new > ioctl it breaks the tests, > however if the ioctl was disabled later shouldn't be current git working > unless another regression happened? Yes, it should. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #7 from Tomi Pieviläinen 2012-02-11 04:20:42 PST --- Sure, I'll see if I can find it on the repos. If not, might take a bit longer. The displayport is connected to an active dp-to-dldvi adapter, which is connected to Samsung SyncMaster 305tplus (monitor with only dldvi input, and accepts only 2560x1600 and 1280x800 modes). The dvi is connected to HP LP2475w, which is pivoted. The APU is A3500 connected to Asus F1A75V_PRO motherboard. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #8 from Tomi Pieviläinen 2012-02-11 04:28:58 PST --- Running now on 3.3rc3, same results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #4 from Pavel Ondračka 2012-02-11 04:51:23 PST --- OK, I can finally see whats going on. ef64da8f013691c66744064769db379e57ef95de fails however 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 + manually applied ef64da8f013691c66744064769db379e57ef95de pass. So indeed a second regression happened :-( Running second bisect right now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added CC||bryancain3+...@gmail.com --- Comment #5 from Pavel Ondračka 2012-02-11 05:59:42 PST --- Marek you were right with the glsl_to_tgsi cause. It indeed seems majority of the commits fails due to some glsl_to_tgsi changes. fs-any-bvec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if regressed with: a43f68810a347f3e952a0bc401be6edb91e1baea is the first bad commit commit a43f68810a347f3e952a0bc401be6edb91e1baea Author: Bryan Cain Date: Sat Aug 20 13:26:12 2011 -0500 glsl_to_tgsi: implement ir_unop_any using DP4 w/saturate or DP4 w/SLT This is a port of commit 92ca560d68e8 to glsl_to_tgsi, with integer support added. glsl1-inequality (vec2, pass) fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-vec2-vec2-using-if regressed with: f3dce133f0422c42ca61f07f488237107efc30e6 is the first bad commit commit f3dce133f0422c42ca61f07f488237107efc30e6 Author: Bryan Cain Date: Sat Aug 20 13:56:06 2011 -0500 glsl_to_tgsi: implement ir_binop_any_nequal using DP4 w/saturate or DP4 w/SLT Implement the any() part of the operation the same way regular ir_unop_any is implemented. This is a port of commit e7bf096e8b04 to glsl_to_tgsi, with added integer support. The rest of the tests (glsl-fs-discard-02, glsl-max-varyings and glsl-vs-loop-redundant-condition) regressed in another (probably 3 different) places. I'll get to them later. BTW this may be the worst bisect I've ever done. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regressions after glsl_to_tgsi changes
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Pavel Ondračka changed: What|Removed |Added Summary|[r300g, bisected] Multiple |[r300g, bisected] Multiple |piglit regression after |piglit regressions after |winsys/radeon: hook up the |glsl_to_tgsi changes |new DRM_RADEON_GEM_WAIT | |ioctl | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #25 from Florian Mickler 2012-02-11 07:51:40 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit 304a48400d9718f74ec35ae46f30868a5f4c4516 Author: Alex Deucher Date: Thu Feb 2 10:18:00 2012 -0500 drm/radeon/kms: fix TRAVIS panel setup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45503] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
https://bugs.freedesktop.org/show_bug.cgi?id=45503 --- Comment #13 from Florian Mickler 2012-02-11 07:52:31 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc3: commit de47a9cd62771e3e78954d855d2304fbad4c5a44 Author: Dave Airlie Date: Thu Feb 2 15:25:16 2012 + drm/radeon: fix use after free in ATRM bios reading code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new
https://bugs.freedesktop.org/show_bug.cgi?id=45907 Alex Deucher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2012-02-11 07:58:31 PST --- fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c565ff60d6fce8c3402e60e6475c03717b297965 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38173] DXT3 and DXT5 broken on Cayman gpu
https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon 9250 pci
On Tue, 07 Feb 2012 19:01:04 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:41 +0100, acrux wrote: > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon 9250 PCI > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > Machine check in kernel mode. > > Data Write PLB Error > > Machine Check exception is imprecise > > Oops: Machine check, sig: 7 [#1] > > Canyonlands > > Modules linked in: > > NIP: c000a580 LR: c0399084 CTR: 000bfffb > > REGS: efff7f10 TRAP: 0214 Not tainted (3.3.0-rc2) > > MSR: 00029000 CR: 24714222 XER: > > TASK = ef83[1] 'swapper' THREAD: ef834000 > > GPR00: ef835c30 ef83 f550 0030 > > ef835bd8 GPR08: ef835b38 f5500014 000c0001 > > 24714284 8500682f ef8f7800 ef17c1c0 GPR16: 0020 c05f > > c06105de ef835d08 c0610351 c056a6f0 c0610600 GPR24: > > fff4 ef8ca47c ef9ffe00 ef9fff38 ef9e7c00 ef835cb8 ef8ea000 > > ef8ca400 NIP [c000a580] _memset_io+0x54/0x90 LR [c0399084] > > radeon_fb_find_or_create_single+0x234/0x42c Call Trace: > > [ef835c30] [c0399068] radeon_fb_find_or_create_single+0x218/0x42c > > (unreliable) > > Again looks like the problem occurs when first accessing VRAM, in this > case for clearing the visible framebuffer contents. > > I wonder if we're missing something to handle device memory access > properly on your machine(s)... Is ioremap_wc() working on them with > other drivers? > > i got a kernel panic also with the legacy radeon framebuffer -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Tue, 07 Feb 2012 18:32:44 +0100 Michel Dänzer wrote: > On Son, 2012-02-05 at 00:38 +0100, acrux wrote: > > > > unable to have a working radeon kms framebuffer with linux-3.3-rc2 > > on ppc video card: Radeon X1650PRO PCIE > > Is this a regression? If yes, can you bisect? > not a regression, i didn't find a working kernel release > > > [drm] GART: num cpu pages 131072, num gpu pages 131072 > > The driver detects the CPU page size as 4K, is that correct? > > it's right, 4k page size Just a curiosity, i've only two powerpc machines[1] equipped with PCIE videocards and both them are not able to boot with radeonkms. Modern PCI-E videocards are not recognized by the old linux framebuffer subsystem and they solely can be managed by the new KMS frame buffer that doesn't work properly on Power Architecture. Anyway, YDL Powerstation can fallback to use the old OpenFirmware frame buffer. KMS porting to Power Architecture machines with PCIE is it only an exercise or someone is also able to test them? Because i can understand that the userbase is non-existent and the dri-developers don't have these "rare" machines. [1] YDL Powerstation, Acube Sam460ex cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45943] New: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Bug #: 45943 Summary: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Classification: Unclassified Product: Mesa Version: git Platform: Other URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi c/webgl/sdk/tests/webgl-conformance-tests.html OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz Created attachment 56904 --> https://bugs.freedesktop.org/attachment.cgi?id=56904 full backtrace Triggered with Firefox 10 at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html (click run tests and wait). Firefox 10 is needed earlier versions doesn't trigger this. radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. r300: Warning: cs_count off by -6 at (r300_emit_aa_state, r300_emit.c:370) radeon: The kernel rejected CS, see dmesg for more information. r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed. Program received signal SIGTRAP, Trace/breakpoint trap. _debug_assert_fail (expr=0x2c2fa6f "(aa->dest)->cs_buf", file=0x2c2fa58 "r300_emit.c", line= 365, function=0x2c2ff77 "r300_emit_aa_state") at util/u_debug.c:281 Full backtrace attached, from dmesg: [50370.978205] [drm:r100_cs_packet_next_reloc] *ERROR* No packet3 for relocation for packet at 13. [50370.978211] [drm] ib[13]=0x13A1 [50370.978214] [drm] ib[14]=0x00C30040 [50370.978217] [drm:r300_packet0_check] *ERROR* No reloc for ib[12]=0x4E80 [50370.978220] [drm] ib[11]=0x13A0 [50370.978223] [drm] ib[12]=0x [50370.978225] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! GPU:RV530 Kernel: 3.2.3 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee Libdrm: 2.4.31 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #2 from lschin...@gmail.com 2012-02-11 16:37:42 UTC --- The workaround work ok -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 Bug #: 45921 Summary: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com Found while comparing piglit results between 7.11 and 8.0 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 is the first bad commit commit 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 Author: Marek Olšák Date: Sun Aug 7 19:04:37 2011 +0200 winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl Reviewed-by: Alex Deucher Regressed tests: glsl1-inequality (vec2, pass) glsl-fs-discard-02 glsl-max-varyings glsl-vs-loop-redundant-condition fs-any-bvec2-using-if fs-op-ne-bvec2-bvec2-using-if fs-op-ne-ivec2-ivec2-using-if fs-op-ne-mat2-mat2-using-if fs-op-ne-vec2-vec2-using-if fs-op-ne-mat2x3-mat2x3-using-if fs-op-ne-mat2x4-mat2x4-using-if and probably some others All those tests pass on 7.11 and fail in both 8.0 and master branch. GPU: RV530 Kernel: 3.2.3 Libdrm: 2.4.31 Mesa: d5a6c172547d8964f4d4bb79637651decaf9deee -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45901] [r300g, bisected] vs-atan-float-float fail
https://bugs.freedesktop.org/show_bug.cgi?id=45901 --- Comment #1 from Pavel Ondračka 2012-02-11 03:11:30 UTC --- glsl-vs-vec4-indexing-temp-dst-in-loop is another test regressed by aforementioned commit. BTW both tests pass with llvmpipe and softpipe, so this is probably just some uncovered r300 compiler bug, not a real regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #1 from Marek Olšák 2012-02-11 03:21:46 PST --- I am sure the commit in question is not the cause. I prematurely added the code for the new ioctl and disabled it later on, because my kernel code the commit was supposed to interact with wasn't accepted. The problem when bisecting is that now it tries to call a non-existing ioctl if the DRM minor version is >=12, which makes some tests fail. Could you please check dmesg to see if that's the case? There should be some error messages from DRM. I think that some of those piglit failures are caused by the glsl-to-tgsi translator. You can disable glsl-to-tgsi by commenting out: functions->LinkShader = st_link_shader; at the end of src/mesa/state_tracker/st_cb_program.c. Anyway, sorry, I won't probably help you with this bug anytime soon. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). Signed-off-by: Yufeng Shen --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_i2c.c | 23 +-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 559fb6f..4ed9fd9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -722,6 +722,8 @@ typedef struct drm_i915_private { u8 corr; spinlock_t *mchdev_lock; + struct mutex gmbus_mutex; + enum no_fbc_reason no_fbc_reason; struct drm_mm_node *compressed_fb; diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index d98cee6..42569b1 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct intel_gmbus, adapter); struct drm_i915_private *dev_priv = adapter->algo_data; - int i, reg_offset; + int i, reg_offset, ret; - if (bus->force_bit) - return intel_i2c_quirk_xfer(dev_priv, + mutex_lock(&dev_priv->gmbus_mutex); + + if (bus->force_bit) { + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); + goto out; + } reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0; @@ -320,7 +324,8 @@ done: * start of the next xfer, till then let it sleep. */ I915_WRITE(GMBUS0 + reg_offset, 0); - return i; + ret = i; + goto out; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", @@ -330,9 +335,13 @@ timeout: /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) - return -ENOMEM; + ret = -ENOMEM; + else + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num); +out: + mutex_unlock(&dev_priv->gmbus_mutex); + return ret; } static u32 gmbus_func(struct i2c_adapter *adapter) @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev) if (dev_priv->gmbus == NULL) return -ENOMEM; + mutex_init(&dev_priv->gmbus_mutex); + for (i = 0; i < GMBUS_NUM_PORTS; i++) { struct intel_gmbus *bus = &dev_priv->gmbus[i]; -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Detect cache domain inconsistency with valgrind
Every access to either the GTT or CPU pointer is supposed to be proceeded by a set_domain ioctl so that GEM is able to manage the cache domains correctly and for the following access to be coherent. Of course, some people explicitly want incoherent, non-blocking access which is going to trigger warnings by this patch but are probably better served by explicit suppression. v2: Also mark the pointers as inaccessible following the explicit unmap and implicit unmap upon return to the cache. Signed-off-by: Chris Wilson --- intel/intel_bufmgr_gem.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 2e65580..3856d3d 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -922,6 +922,20 @@ drm_intel_gem_bo_free(drm_intel_bo *bo) free(bo); } +static void +drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo) +{ +#if HAVE_VALGRIND + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; + + if (bo_gem->mem_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_virtual, bo->size); + + if (bo_gem->gtt_virtual) + VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size); +#endif +} + /** Frees all cached buffers significantly older than @time. */ static void drm_intel_gem_cleanup_bo_cache(drm_intel_bufmgr_gem *bufmgr_gem, time_t time) @@ -1050,6 +1064,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time) DBG("bo freed with non-zero map-count %d\n", bo_gem->map_count); bo_gem->map_count = 0; drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); } DRMLISTDEL(&bo_gem->name_list); @@ -1160,6 +1175,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable) if (write_enable) bo_gem->mapped_cpu_write = true; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->mem_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1240,6 +1257,8 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) strerror(errno)); } + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size); pthread_mutex_unlock(&bufmgr_gem->lock); return 0; @@ -1289,6 +1308,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo) */ if (--bo_gem->map_count == 0) { drm_intel_gem_bo_close_vma(bufmgr_gem, bo_gem); + drm_intel_gem_bo_mark_mmaps_incoherent(bo); bo->virtual = NULL; } pthread_mutex_unlock(&bufmgr_gem->lock); @@ -1615,6 +1635,8 @@ drm_intel_gem_bo_process_reloc(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc(target_bo); @@ -1639,6 +1661,8 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo) if (target_bo == bo) continue; + drm_intel_gem_bo_mark_mmaps_incoherent(bo); + /* Continue walking the tree depth-first. */ drm_intel_gem_bo_process_reloc2(target_bo); -- 1.7.9 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote: > Every access to either the GTT or CPU pointer is supposed to be > proceeded by a set_domain ioctl so that GEM is able to manage the cache > domains correctly and for the following access to be coherent. Of > course, some people explicitly want incoherent, non-blocking access > which is going to trigger warnings by this patch but are probably better > served by explicit suppression. > > v2: Also mark the pointers as inaccessible following the explicit unmap > and implicit unmap upon return to the cache. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #2 from Pavel Ondračka 2012-02-11 03:59:26 UTC --- (In reply to comment #1) > I am sure the commit in question is not the cause. I prematurely added the > code for the new ioctl and disabled it later on, because my kernel code the > commit > was supposed to interact with wasn't accepted. > > The problem when bisecting is that now it tries to call a non-existing ioctl > if the DRM minor version is >=12, which makes some tests fail. Could you > please > check dmesg to see if that's the case? There should be some error messages > from DRM. None of the tests produce any output in dmesg. > > I think that some of those piglit failures are caused by the glsl-to-tgsi > translator. You can disable glsl-to-tgsi by commenting out: > > functions->LinkShader = st_link_shader; > > at the end of src/mesa/state_tracker/st_cb_program.c. From all the mentioned tests only glsl-fs-discard-02 pass when I disable glsl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand that if I don't have kernel with support for the new ioctl it breaks the tests, however if the ioctl was disabled later shouldn't be current git working unless another regression happened? > Anyway, sorry, I won't probably help you with this bug anytime soon. Well, I don't care much for piglit, I just want to make sure r300g don't get too rusty now when the development has moved to new drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #3 from Marek Olšák 2012-02-11 04:19:27 PST --- (In reply to comment #2) > (In reply to comment #1) > > I am sure the commit in question is not the cause. I prematurely added the > > code for the new ioctl and disabled it later on, because my kernel code the > > commit > > was supposed to interact with wasn't accepted. > > > > The problem when bisecting is that now it tries to call a non-existing > > ioctl if the DRM minor version is >=12, which makes some tests fail. Could > > you please > > check dmesg to see if that's the case? There should be some error messages > > from DRM. > > None of the tests produce any output in dmesg. Okay. > > > > I think that some of those piglit failures are caused by the glsl-to-tgsi > > translator. You can disable glsl-to-tgsi by commenting out: > > > > functions->LinkShader = st_link_shader; > > > > at the end of src/mesa/state_tracker/st_cb_program.c. > > From all the mentioned tests only glsl-fs-discard-02 pass when I disable > glsl-to-tgsi. > > BTW in which commit was the new ioctl disabled? In this one: ef64da8f013691c66744064769db379e57ef95de > I mean, I can understand that if I don't have kernel with support for the new > ioctl it breaks the tests, > however if the ioctl was disabled later shouldn't be current git working > unless another regression happened? Yes, it should. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #7 from Tomi Pieviläinen 2012-02-11 04:20:42 PST --- Sure, I'll see if I can find it on the repos. If not, might take a bit longer. The displayport is connected to an active dp-to-dldvi adapter, which is connected to Samsung SyncMaster 305tplus (monitor with only dldvi input, and accepts only 2560x1600 and 1280x800 modes). The dvi is connected to HP LP2475w, which is pivoted. The APU is A3500 connected to Asus F1A75V_PRO motherboard. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45825] Displayport output unusable on Llano
https://bugs.freedesktop.org/show_bug.cgi?id=45825 --- Comment #8 from Tomi Pieviläinen 2012-02-11 04:28:58 PST --- Running now on 3.3rc3, same results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=45921 --- Comment #4 from Pavel Ondračka 2012-02-11 04:51:23 PST --- OK, I can finally see whats going on. ef64da8f013691c66744064769db379e57ef95de fails however 1e3c81a068c4ae04cd1c6b18c687d5be69b7b8c4 + manually applied ef64da8f013691c66744064769db379e57ef95de pass. So indeed a second regression happened :-( Running second bisect right now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel