[Bug 45943] New: [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.

[bugzilla-dae...@freedesktop.org]

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 at lists.freedesktop.org
ReportedBy: pavel.ondracka at 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.

linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

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/

linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon 9250 pci

[acrux]

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/

[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45880

--- Comment #2 from lsching17 at 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.

[Bug 38173] DXT3 and DXT5 broken on Cayman gpu

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45503] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

[bugzilla-dae...@freedesktop.org]

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.

[Bug 41569] [r600 KMS] Asus A53T A4-3400

[bugzilla-dae...@freedesktop.org]

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.

[PATCH] Fix spelling in comments.

[Kristof Ralovich]

Dear All,

attached is the patch.

Kristof

[PATCH] Fix spelling in comments.

[RALOVICH, Kristóf]

---
 xf86drmMode.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xf86drmMode.h b/xf86drmMode.h
index 34f5fb1..febf88a 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -333,7 +333,7 @@ extern int drmModeAddFB2(int fd, uint32_t width, uint32_t 
height,
 uint32_t pitches[4], uint32_t offsets[4],
 uint32_t *buf_id, uint32_t flags);
 /**
- * Destroies the given framebuffer.
+ * Destroys the given framebuffer.
  */
 extern int drmModeRmFB(int fd, uint32_t bufferId);

@@ -349,7 +349,7 @@ extern int drmModeDirtyFB(int fd, uint32_t bufferId,
  */

 /**
- * Retrive information about the ctrt crtcId
+ * Retrive information about the crtc crtcId
  */
 extern drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId);

-- 
1.7.5.4


--090309060904000708050301--

[Bug 45921] [r300g, bisected] Multiple piglit regressions after glsl_to_tgsi changes

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

Pavel Ondra?ka  changed:

   What|Removed |Added

 CC||bryancain3+fdo at 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.

[Intel-gfx] [PATCH] intel: Detect cache domain inconsistency with valgrind

[Daniel Vetter]

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: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45825] Displayport output unusable on Llano

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45825] Displayport output unusable on Llano

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

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.

[PATCH] intel: Detect cache domain inconsistency with valgrind

[Chris Wilson]

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(_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(_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(_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(_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

[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

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.

No subject

sl-to-tgsi.

BTW in which commit was the new ioctl disabled? I mean, I can understand th=
at if I don't have kernel with support for the new ioctl it breaks the test=
s,
however if the ioctl was disabled later shouldn't be current git working un=
less 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 ge=
t too rusty now when the development has moved to new drivers.

--=20
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
--- You are receiving this mail because: ---
You are the assignee for the bug.=

[Bug 45921] New: [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

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 at lists.freedesktop.org
ReportedBy: pavel.ondracka at email.cz
CC: maraeo at 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.

[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45913

Pavel Ondra?ka  changed:

   What|Removed |Added

   Priority|medium  |low
 AssignedTo|mesa-dev at lists.freedesktop. |dri-devel at 
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.

[Bug 38173] DXT3 and DXT5 broken on Cayman gpu

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38173

--- Comment #10 from Alexandre Demers  
2012-02-10 22:06:49 PST ---
It seems to be rendering correctly now for me. Textures and texts that were 
corrupted are now fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45921] [r300g, bisected] Multiple piglit regression after winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45901] [r300g, bisected] vs-atan-float-float fail

[bugzilla-dae...@freedesktop.org]

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.

[Bug 45907] symbol lookup error: /usr/lib64/libXvMCr600.so: undefined symbol: radeon_surface_manager_new

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45907

--- Comment #3 from Kevin DeKorte  2012-02-10 18:01:44 
PST ---
Alex, your suggested fix does correct the problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45825] Displayport output unusable on Llano

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45825

--- Comment #6 from Alex Deucher  2012-02-10 16:53:26 PST 
---
Can you try a 3.3rc3 kernel?  What kind of monitor is attached to the 
Displayport connector?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45825] Displayport output unusable on Llano

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45825

Alex Deucher  changed:

   What|Removed |Added

  Attachment #56820|text/x-log  |text/plain
  mime type||
  Attachment #56820|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45913

Pavel Ondračka pavel.ondra...@email.cz 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 pavel.ondra...@email.cz 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

[bugzilla-daemon]

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 mar...@gmail.com
Date:   Sun Aug 7 19:04:37 2011 +0200

winsys/radeon: hook up the new DRM_RADEON_GEM_WAIT ioctl

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45901

--- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

--- Comment #1 from Marek Olšák mar...@gmail.com 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

[Yufeng Shen]

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 mile...@chromium.org
---
 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

[Chris Wilson]

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 ch...@chris-wilson.co.uk
---
 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

[Daniel Vetter]

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 ch...@chris-wilson.co.uk
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
-- 
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

--- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

--- Comment #3 from Marek Olšák mar...@gmail.com 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45825

--- Comment #7 from Tomi Pieviläinen tomi.pievilainen+freedesk...@iki.fi 
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45825

--- Comment #8 from Tomi Pieviläinen tomi.pievilainen+freedesk...@iki.fi 
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

--- Comment #4 from Pavel Ondračka pavel.ondra...@email.cz 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

 CC||bryancain3+...@gmail.com

--- Comment #5 from Pavel Ondračka pavel.ondra...@email.cz 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 bryanca...@gmail.com
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 bryanca...@gmail.com
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45921

Pavel Ondračka pavel.ondra...@email.cz 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41569

--- Comment #25 from Florian Mickler flor...@mickler.org 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 alexander.deuc...@amd.com
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45503

--- Comment #13 from Florian Mickler flor...@mickler.org 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 airl...@redhat.com
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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45907

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Alex Deucher ag...@yahoo.com 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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=38173

Alex Deucher ag...@yahoo.com 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

[acrux]

On Tue, 07 Feb 2012 19:01:04 +0100
Michel Dänzer mic...@daenzer.net 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 CE,EE,ME  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

[acrux]

On Tue, 07 Feb 2012 18:32:44 +0100
Michel Dänzer mic...@daenzer.net 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.

[bugzilla-daemon]

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)

[bugzilla-daemon]

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