[Bug 30616] r600g glitching in tunnel demo

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss li...@andyfurniss.entadsl.com 2010-12-10 
03:27:33 PST ---
(In reply to comment #0)

Since -

7055068eeae7f64166cca513282829d5a3e9b9d3
r600g: specialized upload manager

I have another test case for high vs low perf.

Nexuiz timedemo demos/demo1 with card/cpu high will after a second -

../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
Assertion `pipe_is_referenced(reference)' failed.

This does not happen with perf low.

-- 
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: 2.6.37-rc2-git7 regression: wine fails to start

[Jean Delvare]

Hi Alex, David,

On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
 On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare kh...@linux-fr.org wrote:
  Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
  following error in the kernel logs:
 
  radeon :07:00.0: r600_cs_track_validate_cb offset[0] 0 2095360 4096 too 
  big
  radeon :07:00.0: r600_packet3_check:1331 invalid cmd stream 484
  [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 
  Hardware is:
  07:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 
  4350]
  07:00.1 Audio device: ATI Technologies Inc RV710/730
 
  X.org version is 7.5.
 
  With kernel 2.6.36, wine works just fine on the same system. Does it
  ring a bell to anyone? Any clue how to investigate this bug? If not, I
  can start a bisection.
 
  I can also provide any additional data you need for investigation.
 
 It's probably this patch:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41
 
 Which exposes a bug in the 3D driver in certain cases.  For some
 reason we get a cb height of 8192 or greater in some cases in the 3D
 driver.  I haven't had time to look into why.  You might try r600g for
 comparison.

Any progress on this? Linus' latest kernel (2.6.37-rc5-git3) still has
the problem. And this is a regression, so I don't think you can just
ignore it.

Is there a bug opened to track this bug already? I couldn't find one on
bugzilla.kernel.org, but maybe I missed it. If there is none, I'll
create one.

-- 
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30616] r600g glitching in tunnel demo

[bugzilla-daemon]

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

--- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com 2010-12-10 
05:01:01 PST ---
(In reply to comment #6)

 Nexuiz timedemo demos/demo1 with card/cpu high will after a second -
 
 ../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
 Assertion `pipe_is_referenced(reference)' failed.
 
 This does not happen with perf low.

Further testing shows that this is unaffected by writeback setting - happens
with 0 or 1.

-- 
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] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Chris Wilson]

Although there may be more than one resource handles pointing to the
Drawable, we only want to destroy it once and only reference the
resource which may have just been deleted on the first instance.

v2: Apply fixes and combine with another bug fix from Michel Dänzer,
https://bugs.freedesktop.org/show_bug.cgi?id=28181

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Michel Dänzer daen...@vmware.com
---
 glx/glxcmds.c |   23 +++
 glx/glxdrawable.h |3 +++
 glx/glxext.c  |   15 ++-
 3 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index de9c3f0..b3ea784 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -529,6 +529,7 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId, 
ClientPtr client,
*error = BadAlloc;
return NULL;
 }
+pGlxDraw-refcnt++;
 
 return pGlxDraw;
 }
@@ -1099,8 +1100,10 @@ __glXDrawableInit(__GLXdrawable *drawable,
 drawable-pDraw = pDraw;
 drawable-type = type;
 drawable-drawId = drawId;
+drawable-otherId = 0;
 drawable-config = config;
 drawable-eventMask = 0;
+drawable-refcnt = 0;
 
 return GL_TRUE;
 }
@@ -1130,14 +1133,18 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen 
*pGlxScreen,
pGlxDraw-destroy (pGlxDraw);
return BadAlloc;
 }
+pGlxDraw-refcnt++;
 
-/* Add the glx drawable under the XID of the underlying X drawable
- * too.  That way we'll get a callback in DrawableGone and can
- * clean up properly when the drawable is destroyed. */
-if (drawableId != glxDrawableId 
-   !AddResource(pDraw-id, __glXDrawableRes, pGlxDraw)) {
-   pGlxDraw-destroy (pGlxDraw);
-   return BadAlloc;
+if (drawableId != glxDrawableId) {
+   /* Add the glx drawable under the XID of the underlying X drawable
+* too.  That way we'll get a callback in DrawableGone and can
+* clean up properly when the drawable is destroyed. */
+   if (!AddResource(drawableId, __glXDrawableRes, pGlxDraw)) {
+   pGlxDraw-destroy (pGlxDraw);
+   return BadAlloc;
+   }
+   pGlxDraw-refcnt++;
+   pGlxDraw-otherId = drawableId;
 }
 
 return Success;
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 2a365c5..80c3234 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -51,8 +51,11 @@ struct __GLXdrawable {
 void  (*waitX)(__GLXdrawable *);
 void  (*waitGL)(__GLXdrawable *);
 
+int refcnt; /* number of resources handles referencing this */
+
 DrawablePtr pDraw;
 XID drawId;
+XID otherId; /* for glx1.3 we need to track the original Drawable as well 
*/
 
 /*
 ** Either GLX_DRAWABLE_PIXMAP, GLX_DRAWABLE_WINDOW or
diff --git a/glx/glxext.c b/glx/glxext.c
index 4bd5d6b..77db8b0 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -128,13 +128,18 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
  * constructors, we added it as a glx drawable resource under both
  * its glx drawable ID and it X drawable ID.  Remove the other
  * resource now so we don't a callback for freed memory. */
-if (glxPriv-drawId != glxPriv-pDraw-id) {
-   if (xid == glxPriv-drawId)
-   FreeResourceByType(glxPriv-pDraw-id, __glXDrawableRes, TRUE);
-   else
-   FreeResourceByType(glxPriv-drawId, __glXDrawableRes, TRUE);
+if (glxPriv-otherId) {
+   XID other = glxPriv-otherId;
+   glxPriv-otherId = 0;
+   if (xid == other)
+   FreeResourceByType(glxPriv-drawId, __glXDrawableRes, TRUE);
+   else
+   FreeResourceByType(other, __glXDrawableRes, TRUE);
 }
 
+if (--glxPriv-refcnt)
+   return True;
+
 for (c = glxAllContexts; c; c = next) {
next = c-next;
if (c-isCurrent  (c-drawPriv == glxPriv || c-readPriv == glxPriv)) 
{
-- 
1.7.2.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Michel Dänzer]

On Fre, 2010-12-10 at 13:38 +, Chris Wilson wrote: 
 Although there may be more than one resource handles pointing to the
 Drawable, we only want to destroy it once and only reference the
 resource which may have just been deleted on the first instance.
 
 v2: Apply fixes and combine with another bug fix from Michel Dänzer,
 https://bugs.freedesktop.org/show_bug.cgi?id=28181
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Kristian Høgsberg k...@bitplanet.net
 Cc: Michel Dänzer daen...@vmware.com

Reviewed-by: Michel Dänzer mic...@daenzer.net

I'd wait for Kristian's review as well though.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm-vblank: Always return true vblank count of scheduled vblank event.

[Mario Kleiner]

 Original Message 
Subject: [PATCH] drm-vblank: Always return true vblank count of 
scheduled vblank event.

Date: Fri, 10 Dec 2010 15:58:10 +0100
From: Mario Kleiner mario.klei...@tuebingen.mpg.de
To: airl...@gmail.com
CC: jbar...@virtuousgeek.org,	k...@bitplanet.net,	Mario Kleiner 
mario.klei...@tuebingen.mpg.de


This patch tries to make sure that the vbl.reply.sequence
vblank count for a queued or emitted vblank event always
corresponds to the true vblank count of queueing/emission, so
the ddx can rely on the returned target_msc for consistency
checks and implementation of swap_intervals in glXSwapBuffers().

Without this there is a small race-condition between the
userspace ddx queueing a vblank event and the vblank
counter incrementing before the event gets queued in
the kernel.

Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
 drivers/gpu/drm/drm_irq.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 4e82d0d..55160d7 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1086,15 +1086,18 @@ static int drm_queue_vblank_event(struct 
drm_device *dev, int pipe,


e-event.sequence = vblwait-request.sequence;
if ((seq - vblwait-request.sequence) = (1  23)) {
+   e-event.sequence = seq;
e-event.tv_sec = now.tv_sec;
e-event.tv_usec = now.tv_usec;
drm_vblank_put(dev, e-pipe);
list_add_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
+   vblwait-reply.sequence = seq;
trace_drm_vblank_event_delivered(current-pid, pipe,
 vblwait-request.sequence);
} else {
list_add_tail(e-base.link, dev-vblank_event_list);
+   vblwait-reply.sequence = vblwait-request.sequence;
}

spin_unlock_irqrestore(dev-event_lock, flags);
--
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC] New connector name...

[Thomas Hellstrom]

Hi!

We're looking at changing the connector names for the vmwgfx module from 
LVDSx to something more relevant for virtual machine windows. Looking at 
something like VMwindow.


Does anybody have any input on this? Comments appreciated.

/Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] check_patch.pl: fix spaces

[Toralf Förster]

Signed-off-by: Toralf Förster toralf.foers...@gmx.de
---
 drivers/gpu/drm/i915/i915_debugfs.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 1f4f3ce..7232fcd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -244,13 +244,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, void *data)
 
 			if (work-old_fb_obj) {
 struct drm_i915_gem_object *obj_priv = to_intel_bo(work-old_fb_obj);
-if(obj_priv)
-	seq_printf(m, Old framebuffer gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+if (obj_priv)
+	seq_printf(m, Old framebuffer gtt_offset 0x%08x\n, obj_priv-gtt_offset);
 			}
 			if (work-pending_flip_obj) {
 struct drm_i915_gem_object *obj_priv = to_intel_bo(work-pending_flip_obj);
-if(obj_priv)
-	seq_printf(m, New framebuffer gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+if (obj_priv)
+	seq_printf(m, New framebuffer gtt_offset 0x%08x\n, obj_priv-gtt_offset);
 			}
 		}
 		spin_unlock_irqrestore(dev-event_lock, flags);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30616] r600g glitching in tunnel demo

[bugzilla-daemon]

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

--- Comment #8 from Jerome Glisse gli...@freedesktop.org 2010-12-10 07:40:19 
PST ---
the assert should give a bigger message, like a trace please paste it here

-- 
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 32296] New: [r300g] Screen corruption with WoW when HyperZ enabled.

[bugzilla-daemon]

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

   Summary: [r300g] Screen corruption with WoW when HyperZ
enabled.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: ranki...@googlemail.com


Created an attachment (id=40990)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=40990)
Screen corruption with HyperZ enabled.

I have upgraded to the 2.6.36.2 Linux kernel, and tried to enable HyperZ for
World of Warcraft using RADEON_HYPERZ=1. Upon entering the game, the bottom
part of the screen is corrupt. (See attachment.)

This happens with both my RV350 and my M66. The blank area starts of correctly
textured, but quickly becomes a blank area in a single colour.

-- 
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 32297] New: [r300g] WoW crashes on exit, when run in a window instead of full-screen.

[bugzilla-daemon]

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

   Summary: [r300g] WoW crashes on exit, when run in a window
instead of full-screen.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: ranki...@googlemail.com


Tested with my RV350, Linux 2.6.36.2 kernel, with WoW running in a 1152x864
window instead of full-screen. On exiting WoW, it crashes with the following
stack trace:

Backtrace:
=0 0x7d88bbf7 dri2_invalidate_drawable+0x47(dPriv=*** Invalid address
0x0032eda8 ***
Internal symbol error: unable to access memory location 0x32eda8)
[/home/chris/Programs/mesa/src/gallium/state_trackers/dri/drm/dri2.c:60] in
r300_dri.so (0x0032edc0)
  1 0x7e9542fb dri2InvalidateBuffers+0x2a(dpy=*** Invalid address 0x0032edc8
***
Internal symbol error: unable to access memory location 0x32edc8, drawable=***
Invalid address 0x0032edcc ***
) [/home/chris/Programs/mesa/src/glx/dri2_glx.c:678] in libgl.so.1 (0x0032ee00)
  2 0x7e95496f DRI2WireToEvent+0x11e(dpy=*** Invalid address 0x0032ee08 ***
Internal symbol error: unable to access memory location 0x32ee08, event=***
Invalid address 0x0032ee0c ***
Internal symbol error: unable to access memory location 0x32ee0c, wire=***
Invalid address 0x0032ee10 ***
Internal symbol error: unable to access memory location 0x32ee10)
[/home/chris/Programs/mesa/src/glx/dri2.c:136] in libgl.so.1 (0x0032ee40)
  3 0x7e9a9dd1 _XEnq+0x60() in libx11.so.6 (0x0032ee90)
  4 0x7e9b0a64 in libx11.so.6 (+0x42a63) (0x0032eeb0)
  5 0x7e9b10f8 _XEventsQueued+0x67() in libx11.so.6 (0x0032eed0)
  6 0x7e9b119a _XFlush+0x49() in libx11.so.6 (0x0032eef0)
  7 0x7e988eb2 XFlush+0x31() in libx11.so.6 (0x0032f000)
  8 0x7dd7087a X11DRV_WindowPosChanged+0x199() in winex11 (0x0032f100)
  9 0x7ed2ff32 USER_SetWindowPos+0x6e1() in user32 (0x0032f240)
  10 0x7ed2f2d7 SetWindowPos+0xa6() in user32 (0x0032f2c0)
  11 0x7ed30e95 WINPOS_ShowIconTitle+0xf4() in user32 (0x0032f310)
  12 0x7ed31bd4 show_window+0x513() in user32 (0x0032f390)
  13 0x7ed31cdb ShowWindow+0x6a() in user32 (0x0032f3c0)
  14 0x007b2651 in wow (+0x3b2650) (0x0032f3d4)
  15 0x007b1008 in wow (+0x3b1007) (0x0032f444)
  16 0x7ed33e1a WINPROC_wrapper+0x19() in user32 (0x0032f474)
  17 0x7ed3456c call_window_proc+0x5b() in user32 (0x0032f4c4)
  18 0x7ed351fc WINPROC_CallProcWtoA+0x90b() in user32 (0x0032fb54)

-- 
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] check_patch.pl: fix spaces

[Toralf Förster]

Signed-off-by: Toralf Förster toralf.foers...@gmx.de
---
 drivers/gpu/drm/i915/i915_debugfs.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1f4f3ce..7232fcd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -244,13 +244,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
void *data)
 
if (work-old_fb_obj) {
struct drm_i915_gem_object *obj_priv = 
to_intel_bo(work-old_fb_obj);
-   if(obj_priv)
-   seq_printf(m, Old framebuffer 
gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+   if (obj_priv)
+   seq_printf(m, Old framebuffer 
gtt_offset 0x%08x\n, obj_priv-gtt_offset);
}
if (work-pending_flip_obj) {
struct drm_i915_gem_object *obj_priv = 
to_intel_bo(work-pending_flip_obj);
-   if(obj_priv)
-   seq_printf(m, New framebuffer 
gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+   if (obj_priv)
+   seq_printf(m, New framebuffer 
gtt_offset 0x%08x\n, obj_priv-gtt_offset);
}
}
spin_unlock_irqrestore(dev-event_lock, flags);
-- 
1.7.2.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [stable] [PATCH] drm/kms: remove spaces from connector names

[Sergej Pupykin]

At Thu, 9 Dec 2010 09:18:14 -0800,
Jesse Barnes jbar...@virtuousgeek.org wrote:
 
 And it's ugly; can't we fix grub instead?

I am searching for bootloader which can pass whitespaces. It looks
like we should patch grub-legacy (0.97), grub (1.98) and lilo...

(I did not try lilo yet, but man page says nothing about passing
spaces in 'append=' option description)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30616] r600g glitching in tunnel demo

[bugzilla-daemon]

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

--- Comment #9 from Andy Furniss li...@andyfurniss.entadsl.com 2010-12-10 
10:05:10 PST ---
(In reply to comment #8)
 the assert should give a bigger message, like a trace please paste it here

It doesn't give a trace  - running the binary direct just gives

Trace/breakpoint trap

I've tried gdb but it doesn't assert when running under it.

-- 
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: [stable] [PATCH] drm/kms: remove spaces from connector names

[Peter Stuge]

Sergej Pupykin wrote:
  And it's ugly; can't we fix grub instead?
 
 I am searching for bootloader which can pass whitespaces. It looks
 like we should patch grub-legacy (0.97), grub (1.98) and lilo...
 
 (I did not try lilo yet, but man page says nothing about passing
 spaces in 'append=' option description)

append can contain any arbitrary string, which will be parsed by the
kernel. I e.g. use:

append=root=/dev/sda2 snd_ac97_codec.power_save=1 usbcore.autosuspend=1 
hpet=force quiet drm_kms_helper.poll=0

And grub also supports an append string with spaces, that is probably
used by every distribution.

The question is, what will the kernel parser do about that space?


//Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30616] r600g glitching in tunnel demo

[bugzilla-daemon]

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

--- Comment #10 from Andy Furniss li...@andyfurniss.entadsl.com 2010-12-10 
11:26:49 PST ---
(In reply to comment #9)

 I've tried gdb but it doesn't assert when running under it.

Sauerbraten is also affected, whatever perf is set to.
It also works with gdb -  


../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
Assertion `pipe_is_referenced(reference)' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb72746d0 (LWP 7870)]
_debug_assert_fail (expr=0xb65b2b3f pipe_is_referenced(reference),
file=0xb65b4fec ../../../../../src/gallium/auxiliary/util/u_inlines.h,
line=81, function=0xb65b9555 pipe_reference_described) at util/u_debug.c:237
237 }
(gdb) bt
#0  _debug_assert_fail (expr=0xb65b2b3f pipe_is_referenced(reference),
file=0xb65b4fec ../../../../../src/gallium/auxiliary/util/u_inlines.h,
line=81, function=0xb65b9555 pipe_reference_described) at util/u_debug.c:237
#1  0xb63a533a in r600_bo_reference (radeon=0x8823678, dst=0x8b13dec,
src=0xe47de78) at ../../../../../src/gallium/auxiliary/util/u_inlines.h:81
#2  0xb63a8570 in r600_context_pipe_state_set_fs_resource (ctx=0x8838ad0,
state=0xb62bb810, rid=1) at r600_hw_context.c:878
#3  0xb63853b1 in r600_vertex_buffer_update (rctx=0x8838948) at
r600_state.c:201
#4  0xb63965ef in r600_bind_vertex_elements (ctx=0x8838948, state=0x8b3f118) at
r600_state_common.c:129
#5  0xb656da57 in util_blitter_clear (blitter=0x8b3aad8, width=1024,
height=768, num_cbufs=1, clear_buffers=value optimized out, rgba=0x8b4551c,
depth=1, stencil=0) at util/u_blitter.c:693
#6  0xb6399773 in r600_clear (ctx=0x8838948, buffers=1, rgba=0x8b4551c,
depth=1, stencil=0) at r600_blit.c:122
#7  0xb6506368 in st_Clear (ctx=0x8b44810, mask=2) at
state_tracker/st_cb_clear.c:550
#8  0xb64bc65a in _mesa_Clear (mask=16384) at main/clear.c:241
#9  0x08082abe in ?? ()
#10 0x0815f7be in ?? ()
#11 0x0818fdfd in ?? ()
#12 0x08194bf3 in ?? ()
#13 0x0805c49e in ?? ()
#14 0x0812d1bc in ?? ()
#15 0x0812dafd in ?? ()
#16 0x0819a333 in ?? ()
#17 0x0812e116 in ?? ()
#18 0x0805ca6a in ?? ()
#19 0x0818b2c5 in ?? ()
#20 0x0808486a in ?? ()
#21 0xb73ef380 in __libc_start_main () from /lib/libc.so.6
#22 0x0804c791 in ?? ()

-- 
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 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

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

--- Comment #3 from Ian Romanick i...@freedesktop.org 2010-12-10 13:42:47 PST 
---
(In reply to comment #2)
 I wonder if lowering DDX/DDY to SFL makes any difference compared to using a
 shader that outputs (0,0,0,1).

The lowering pass I was referring to would happen long before the Mesa IR
level.  At that point there is no SFL instruction.  We'd just replace the
ir_unop_dFdx and ir_unop_dFdy expressions with constants of 0 in the
appropriate type.  Backends (e.g., ir_to_mesa) can convert these constants to
whatever is appropriate.  This way backends for GPUs that can't handle these
operations will never even see them.  That is, after all, the whole point of
the various lowering passes in the GLSL compiler. :)

-- 
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 32307] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting

[bugzilla-daemon]

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

   Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting
   Product: DRI
   Version: XOrg 6.7.0
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: gmalazdrew...@gmail.com


Created an attachment (id=40995)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=40995)
ATI HD5850 BIOS

Similar to 32066, separate because it is a different card, and the BIOS is
stuck in a different place.

2.6.37~rc5
gera...@envy17:~$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Broadway PRO [Mobility
Radeon HD 5800 Series]


[  286.000608] PM: Restoring platform NVS memory
[  286.949320] PM: early resume of devices complete after 1.683 msecs
[  286.950283] r8169 :03:00.0: PME# disabled
[  292.103312] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[  292.103316] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CECA (len 67, WS 0, PS 0) @ 0xCEF9
[  348.132820] PM: resume of devices complete after 61227.467 msecs
[  348.156549] PM: Finishing wakeup.

-- 
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 32240] Second Life crashes on starting ( Linux 32-bit )

[bugzilla-daemon]

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

Ian Romanick i...@freedesktop.org changed:

   What|Removed |Added

  Component|Drivers/DRI/r300|glsl-compiler
 AssignedTo|dri-de...@lists.freedesktop |i...@freedesktop.org
   |.org|

-- 
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: Intel DRM driver for SNB

[Segovia, Benjamin]

Thanks for the answer

I actually have no a rather simple prototype doing shared memory between CPU 
and GPU. Basically:
1/ I create a buffer B
2/ I map B and get a pointer to it
3/ I exec a batch buffer with B still mapped (ugly) and B pointed via a surface 
state internally 
4/ CPU and GPU are communicating throught B

To make things cleaner, I would like to let a non-root user pin the buffer in 
GTT (so change the ioctl rights) and write one more ioctl to make the CPU pages 
unevictable in shmfs (if I am right)

I would like to write an external module on top of i915 for these two 
functions. However, I am not sure I can get symbols from i915 properly. Is a 
i915 patch the only solution? 

Cheers,
Ben


From: Zhenyu Wang [zhen...@linux.intel.com]
Sent: Monday, December 06, 2010 11:00 PM
To: Segovia, Benjamin
Cc: DRI
Subject: Re: Intel DRM driver for SNB

On 2010.12.06 15:18:02 -0800, Segovia, Benjamin wrote:
 Hello all,
 is the kernel driver configured to support reads/writes to LLC (last level 
 cache i.e. L3) on SNB?

Now it's under limited use for the buffer that is sure to be cached,
e.g hw status page, etc. code lives in drivers/char/agp/intel-gtt.c.

--
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32312] New: openvg lion demo freezes the system lockup GPU with r600g

[bugzilla-daemon]

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

   Summary: openvg lion demo freezes the system  lockup GPU
with r600g
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: virtuous...@gmail.com


in time of bug #30684 r600g were giving poor performance with lion demo
(about ~30 fps on my system) but not long ago i've noticed big, x10 time
speedup (up to ~350 fps). however, it was not for long: with
783e7caadf945f176cb297b8791769e2855fc9ef revision launching lion demo on my
system results in
1) video system freeze
2) 100% CPU time usage on all cores and total system freeze up if i not act
quickly and not kill demo process via ssh fast

if killed in time - all goes back to normal, in exception of
launching gles1gears demo right after which results in same behaviour.
however, repeated launch of gles1gears results in working demo but with some
artefacts.
third launch is all ok.

i'm pretty sure that regression was introduced in r600g in last 48 ~hours (same
revision but with r300g work ok) but i haven't done bisect.

-- 
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 32312] openvg lion demo freezes the system lockup GPU with r600g

[bugzilla-daemon]

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

--- Comment #1 from Sergey Kondakov virtuous...@gmail.com 2010-12-10 20:45:37 
PST ---
Created an attachment (id=41000)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41000)
dmesg lockup info

all lockup info from dmesg.

there is also drm initialization info:
[0.319258] [drm] Initialized drm 1.1.0 20060810
[0.319366] [drm] radeon defaulting to kernel modesetting.
[0.319422] [drm] radeon kernel modesetting enabled.
[0.322089] [drm] initializing kernel modesetting (RV770 0x1002:0x944E).
[0.322209] [drm] register mmio base: 0xFDFE
[0.322263] [drm] register mmio size: 65536
[0.323107] [drm] Detected VRAM RAM=512M, BAR=256M
[0.323170] [drm] RAM width 128bits DDR
[0.323424] [drm] radeon: 512M of VRAM memory ready
[0.323479] [drm] radeon: 512M of GTT memory ready.
[0.323658] [drm] radeon: irq initialized.
[0.323713] [drm] GART: num cpu pages 131072, num gpu pages 131072
[0.325293] [drm] Loading RV770 Microcode
[0.373514] [drm] ring test succeeded in 1 usecs
[0.373681] [drm] radeon: ib pool ready.
[0.373759] [drm] ib test succeeded in 0 usecs
[0.373816] [drm] Enabling audio support
[0.374567] [drm] Radeon Display Connectors
[0.374623] [drm] Connector 0:
[0.374676] [drm]   DVI-I
[0.374730] [drm]   HPD2
[0.374784] [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c
0x7e6c
[0.374843] [drm]   Encoders:
[0.375863] [drm] DFP1: INTERNAL_UNIPHY
[0.375918] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[0.375972] [drm] Connector 1:
[0.376032] [drm]   DIN
[0.376085] [drm]   Encoders:
[0.376138] [drm] TV1: INTERNAL_KLDSCP_DAC2
[0.376192] [drm] Connector 2:
[0.376246] [drm]   DVI-I
[0.376298] [drm]   HPD1
[0.376352] [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c
0x7e2c
[0.376411] [drm]   Encoders:
[0.376464] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[0.376518] [drm] DFP2: INTERNAL_KLDSCP_LVTMA
[0.432622] [drm] Internal thermal controller without fan control
[0.432755] [drm] radeon: power management initialized
[0.517044] [drm] fb mappable at 0xD0142000
[0.517099] [drm] vram apper at 0xD000
[0.517153] [drm] size 8294400
[0.517207] [drm] fb depth is 24
[0.517260] [drm]pitch is 7680
[0.517405] fbcon: radeondrmfb (fb0) is primary device
[0.931659] fb0: radeondrmfb frame buffer device
[0.931690] drm: registered panic notifier
[0.931721] [drm] Initialized radeon 2.7.0 20080528 for :01:00.0 on
minor 0

and, by the way, color tiling is enabled and forced-on in X but i doubt is has
anything to do with it.

-- 
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 30616] r600g glitching in tunnel demo

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

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

--- Comment #6 from Andy Furniss  2010-12-10 
03:27:33 PST ---
(In reply to comment #0)

Since -

7055068eeae7f64166cca513282829d5a3e9b9d3
r600g: specialized upload manager

I have another test case for high vs low perf.

Nexuiz timedemo demos/demo1 with card/cpu high will after a second -

../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
Assertion `pipe_is_referenced(reference)' failed.

This does not happen with perf low.

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

2.6.37-rc2-git7 regression: wine fails to start

[Jean Delvare]

Hi Alex, David,

On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare  wrote:
> > Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
> > following error in the kernel logs:
> >
> > radeon :07:00.0: r600_cs_track_validate_cb offset[0] 0 2095360 4096 too 
> > big
> > radeon :07:00.0: r600_packet3_check:1331 invalid cmd stream 484
> > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
> >
> > Hardware is:
> > 07:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 
> > 4350]
> > 07:00.1 Audio device: ATI Technologies Inc RV710/730
> >
> > X.org version is 7.5.
> >
> > With kernel 2.6.36, wine works just fine on the same system. Does it
> > ring a bell to anyone? Any clue how to investigate this bug? If not, I
> > can start a bisection.
> >
> > I can also provide any additional data you need for investigation.
> 
> It's probably this patch:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41
> 
> Which exposes a bug in the 3D driver in certain cases.  For some
> reason we get a cb height of 8192 or greater in some cases in the 3D
> driver.  I haven't had time to look into why.  You might try r600g for
> comparison.

Any progress on this? Linus' latest kernel (2.6.37-rc5-git3) still has
the problem. And this is a regression, so I don't think you can just
ignore it.

Is there a bug opened to track this bug already? I couldn't find one on
bugzilla.kernel.org, but maybe I missed it. If there is none, I'll
create one.

-- 
Jean Delvare

[PATCH] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Chris Wilson]

Although there may be more than one resource handles pointing to the
Drawable, we only want to destroy it once and only reference the
resource which may have just been deleted on the first instance.

Signed-off-by: Chris Wilson 
Cc: Kristian H?gsberg 
Cc: Michel D?nzer 
---
 glx/glxcmds.c |6 ++
 glx/glxdrawable.h |3 +++
 glx/glxext.c  |   15 ++-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index de9c3f0..fa153d5 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -529,6 +529,7 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId, 
ClientPtr client,
*error = BadAlloc;
return NULL;
 }
+pGlxDraw->refcnt++;

 return pGlxDraw;
 }
@@ -1099,8 +1100,10 @@ __glXDrawableInit(__GLXdrawable *drawable,
 drawable->pDraw = pDraw;
 drawable->type = type;
 drawable->drawId = drawId;
+drawable->otherId = 0;
 drawable->config = config;
 drawable->eventMask = 0;
+drawable->refcnt = 0;

 return GL_TRUE;
 }
@@ -1130,6 +1133,7 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen 
*pGlxScreen,
pGlxDraw->destroy (pGlxDraw);
return BadAlloc;
 }
+pGlxDraw->refcnt++;

 /* Add the glx drawable under the XID of the underlying X drawable
  * too.  That way we'll get a callback in DrawableGone and can
@@ -1139,6 +1143,8 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen 
*pGlxScreen,
pGlxDraw->destroy (pGlxDraw);
return BadAlloc;
 }
+pGlxDraw->refcnt++;
+pGlxDraw->otherId = pDraw->id;

 return Success;
 }
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 2a365c5..80c3234 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -51,8 +51,11 @@ struct __GLXdrawable {
 void  (*waitX)(__GLXdrawable *);
 void  (*waitGL)(__GLXdrawable *);

+int refcnt; /* number of resources handles referencing this */
+
 DrawablePtr pDraw;
 XID drawId;
+XID otherId; /* for glx1.3 we need to track the original Drawable as well 
*/

 /*
 ** Either GLX_DRAWABLE_PIXMAP, GLX_DRAWABLE_WINDOW or
diff --git a/glx/glxext.c b/glx/glxext.c
index 4bd5d6b..c473aa9 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -128,13 +128,18 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
  * constructors, we added it as a glx drawable resource under both
  * its glx drawable ID and it X drawable ID.  Remove the other
  * resource now so we don't a callback for freed memory. */
-if (glxPriv->drawId != glxPriv->pDraw->id) {
-   if (xid == glxPriv->drawId)
-   FreeResourceByType(glxPriv->pDraw->id, __glXDrawableRes, TRUE);
-   else
-   FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
+if (glxPriv->otherId) {
+   XID other = glxPriv->otherId;
+   glxPriv->otherId = 0;
+   if (xid == other)
+   FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
+   else
+   FreeResourceByType(other, __glXDrawableRes, TRUE);
 }

+if (--glxPriv->refcnt)
+   return TRUE;
+
 for (c = glxAllContexts; c; c = next) {
next = c->next;
if (c->isCurrent && (c->drawPriv == glxPriv || c->readPriv == glxPriv)) 
{
-- 
1.7.2.3

[Bug 30616] r600g glitching in tunnel demo

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

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

--- Comment #7 from Andy Furniss  2010-12-10 
05:01:01 PST ---
(In reply to comment #6)

> Nexuiz timedemo demos/demo1 with card/cpu high will after a second -
> 
> ../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
> Assertion `pipe_is_referenced(reference)' failed.
> 
> This does not happen with perf low.

Further testing shows that this is unaffected by writeback setting - happens
with 0 or 1.

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

[PATCH] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Michel Dänzer]

On Fre, 2010-12-10 at 12:43 +, Chris Wilson wrote: 
> Although there may be more than one resource handles pointing to the
> Drawable, we only want to destroy it once and only reference the
> resource which may have just been deleted on the first instance.
> 
> Signed-off-by: Chris Wilson 
> Cc: Kristian H?gsberg 
> Cc: Michel D?nzer 
> ---
>  glx/glxcmds.c |6 ++
>  glx/glxdrawable.h |3 +++
>  glx/glxext.c  |   15 ++-
>  3 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index de9c3f0..fa153d5 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -1139,6 +1143,8 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen 
> *pGlxScreen,
>   pGlxDraw->destroy (pGlxDraw);
>   return BadAlloc;
>  }
> +pGlxDraw->refcnt++;
> +pGlxDraw->otherId = pDraw->id;

I think this should use drawableId instead of pDraw->id, and refcnt
should only be incremented if it's different from glxDrawableId.
Combined with the patch I attached to
https://bugs.freedesktop.org/show_bug.cgi?id=28181 this block could look
something like

if (drawableId != glxDrawableId) {
/* Add the glx drawable under the XID of the underlying X drawable
 * too.  That way we'll get a callback in DrawableGone and can
 * clean up properly when the drawable is destroyed. */
if (!AddResource(drawableId, __glXDrawableRes, pGlxDraw)) {
pGlxDraw->destroy (pGlxDraw);
return BadAlloc;
}

pGlxDraw->refcnt++;
pGlxDraw->otherId = pDraw->id;
}

Then this patch will hopefully address that bug and maybe others with
references to DrawableGone. Fingers crossed. :)


> diff --git a/glx/glxext.c b/glx/glxext.c
> index 4bd5d6b..c473aa9 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -128,13 +128,18 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID 
> xid)
>   * constructors, we added it as a glx drawable resource under both
>   * its glx drawable ID and it X drawable ID.  Remove the other
>   * resource now so we don't a callback for freed memory. */
> -if (glxPriv->drawId != glxPriv->pDraw->id) {
> - if (xid == glxPriv->drawId)
> - FreeResourceByType(glxPriv->pDraw->id, __glXDrawableRes, TRUE);
> - else
> - FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
> +if (glxPriv->otherId) {
> + XID other = glxPriv->otherId;
> + glxPriv->otherId = 0;
> + if (xid == other)
> + FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
> + else
> + FreeResourceByType(other, __glXDrawableRes, TRUE);
>  }
>  
> +if (--glxPriv->refcnt)
> + return TRUE;

The return at the end of the function uses True instead of TRUE.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Chris Wilson]

Although there may be more than one resource handles pointing to the
Drawable, we only want to destroy it once and only reference the
resource which may have just been deleted on the first instance.

v2: Apply fixes and combine with another bug fix from Michel D?nzer,
https://bugs.freedesktop.org/show_bug.cgi?id=28181

Signed-off-by: Chris Wilson 
Cc: Kristian H?gsberg 
Cc: Michel D?nzer 
---
 glx/glxcmds.c |   23 +++
 glx/glxdrawable.h |3 +++
 glx/glxext.c  |   15 ++-
 3 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index de9c3f0..b3ea784 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -529,6 +529,7 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId, 
ClientPtr client,
*error = BadAlloc;
return NULL;
 }
+pGlxDraw->refcnt++;

 return pGlxDraw;
 }
@@ -1099,8 +1100,10 @@ __glXDrawableInit(__GLXdrawable *drawable,
 drawable->pDraw = pDraw;
 drawable->type = type;
 drawable->drawId = drawId;
+drawable->otherId = 0;
 drawable->config = config;
 drawable->eventMask = 0;
+drawable->refcnt = 0;

 return GL_TRUE;
 }
@@ -1130,14 +1133,18 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen 
*pGlxScreen,
pGlxDraw->destroy (pGlxDraw);
return BadAlloc;
 }
+pGlxDraw->refcnt++;

-/* Add the glx drawable under the XID of the underlying X drawable
- * too.  That way we'll get a callback in DrawableGone and can
- * clean up properly when the drawable is destroyed. */
-if (drawableId != glxDrawableId &&
-   !AddResource(pDraw->id, __glXDrawableRes, pGlxDraw)) {
-   pGlxDraw->destroy (pGlxDraw);
-   return BadAlloc;
+if (drawableId != glxDrawableId) {
+   /* Add the glx drawable under the XID of the underlying X drawable
+* too.  That way we'll get a callback in DrawableGone and can
+* clean up properly when the drawable is destroyed. */
+   if (!AddResource(drawableId, __glXDrawableRes, pGlxDraw)) {
+   pGlxDraw->destroy (pGlxDraw);
+   return BadAlloc;
+   }
+   pGlxDraw->refcnt++;
+   pGlxDraw->otherId = drawableId;
 }

 return Success;
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 2a365c5..80c3234 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -51,8 +51,11 @@ struct __GLXdrawable {
 void  (*waitX)(__GLXdrawable *);
 void  (*waitGL)(__GLXdrawable *);

+int refcnt; /* number of resources handles referencing this */
+
 DrawablePtr pDraw;
 XID drawId;
+XID otherId; /* for glx1.3 we need to track the original Drawable as well 
*/

 /*
 ** Either GLX_DRAWABLE_PIXMAP, GLX_DRAWABLE_WINDOW or
diff --git a/glx/glxext.c b/glx/glxext.c
index 4bd5d6b..77db8b0 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -128,13 +128,18 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
  * constructors, we added it as a glx drawable resource under both
  * its glx drawable ID and it X drawable ID.  Remove the other
  * resource now so we don't a callback for freed memory. */
-if (glxPriv->drawId != glxPriv->pDraw->id) {
-   if (xid == glxPriv->drawId)
-   FreeResourceByType(glxPriv->pDraw->id, __glXDrawableRes, TRUE);
-   else
-   FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
+if (glxPriv->otherId) {
+   XID other = glxPriv->otherId;
+   glxPriv->otherId = 0;
+   if (xid == other)
+   FreeResourceByType(glxPriv->drawId, __glXDrawableRes, TRUE);
+   else
+   FreeResourceByType(other, __glXDrawableRes, TRUE);
 }

+if (--glxPriv->refcnt)
+   return True;
+
 for (c = glxAllContexts; c; c = next) {
next = c->next;
if (c->isCurrent && (c->drawPriv == glxPriv || c->readPriv == glxPriv)) 
{
-- 
1.7.2.3

[PATCH] glx: Refcnt the GLXDrawable to avoid use after free with multiple FreeResource

[Michel Dänzer]

On Fre, 2010-12-10 at 13:38 +, Chris Wilson wrote: 
> Although there may be more than one resource handles pointing to the
> Drawable, we only want to destroy it once and only reference the
> resource which may have just been deleted on the first instance.
> 
> v2: Apply fixes and combine with another bug fix from Michel D?nzer,
> https://bugs.freedesktop.org/show_bug.cgi?id=28181
> 
> Signed-off-by: Chris Wilson 
> Cc: Kristian H?gsberg 
> Cc: Michel D?nzer 

Reviewed-by: Michel D?nzer 

I'd wait for Kristian's review as well though.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] drm-vblank: Always return true vblank count of scheduled vblank event.

[Mario Kleiner]

 Original Message 
Subject: [PATCH] drm-vblank: Always return true vblank count of 
scheduled vblank event.
Date: Fri, 10 Dec 2010 15:58:10 +0100
From: Mario Kleiner 
To: airlied at gmail.com
CC: jbarnes at virtuousgeek.org,krh at bitplanet.net,   Mario Kleiner 


This patch tries to make sure that the vbl.reply.sequence
vblank count for a queued or emitted vblank event always
corresponds to the true vblank count of queueing/emission, so
the ddx can rely on the returned target_msc for consistency
checks and implementation of swap_intervals in glXSwapBuffers().

Without this there is a small race-condition between the
userspace ddx queueing a vblank event and the vblank
counter incrementing before the event gets queued in
the kernel.

Signed-off-by: Mario Kleiner 
---
  drivers/gpu/drm/drm_irq.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 4e82d0d..55160d7 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1086,15 +1086,18 @@ static int drm_queue_vblank_event(struct 
drm_device *dev, int pipe,

e->event.sequence = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
+   e->event.sequence = seq;
e->event.tv_sec = now.tv_sec;
e->event.tv_usec = now.tv_usec;
drm_vblank_put(dev, e->pipe);
list_add_tail(>base.link, >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
+   vblwait->reply.sequence = seq;
trace_drm_vblank_event_delivered(current->pid, pipe,
 vblwait->request.sequence);
} else {
list_add_tail(>base.link, >vblank_event_list);
+   vblwait->reply.sequence = vblwait->request.sequence;
}

spin_unlock_irqrestore(>event_lock, flags);
-- 
1.7.0.4

[RFC] New connector name...

[Thomas Hellstrom]

Hi!

We're looking at changing the connector names for the vmwgfx module from 
LVDSx to something more relevant for virtual machine windows. Looking at 
something like "VMwindow".

Does anybody have any input on this? Comments appreciated.

/Thomas

[PATCH] check_patch.pl: fix spaces

[Toralf Förster]

Signed-off-by: Toralf F?rster 
---
 drivers/gpu/drm/i915/i915_debugfs.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

-- next part --
A non-text attachment was scrubbed...
Name: 0001-check_patch.pl-fix-spaces.patch
Type: text/x-patch
Size: 982 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101210/b37e4c50/attachment.bin>

[Bug 30616] r600g glitching in tunnel demo

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

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

--- Comment #8 from Jerome Glisse  2010-12-10 
07:40:19 PST ---
the assert should give a bigger message, like a trace please paste it here

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

[Bug 32296] New: [r300g] Screen corruption with WoW when HyperZ enabled.

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

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

   Summary: [r300g] Screen corruption with WoW when HyperZ
enabled.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: rankincj at googlemail.com


Created an attachment (id=40990)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=40990)
Screen corruption with HyperZ enabled.

I have upgraded to the 2.6.36.2 Linux kernel, and tried to enable HyperZ for
World of Warcraft using RADEON_HYPERZ=1. Upon entering the game, the bottom
part of the screen is corrupt. (See attachment.)

This happens with both my RV350 and my M66. The blank area starts of correctly
textured, but quickly becomes a blank area in a single colour.

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

[Bug 32297] New: [r300g] WoW crashes on exit, when run in a window instead of full-screen.

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

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

   Summary: [r300g] WoW crashes on exit, when run in a window
instead of full-screen.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: rankincj at googlemail.com


Tested with my RV350, Linux 2.6.36.2 kernel, with WoW running in a 1152x864
window instead of full-screen. On exiting WoW, it crashes with the following
stack trace:

Backtrace:
=>0 0x7d88bbf7 dri2_invalidate_drawable+0x47(dPriv=*** Invalid address
0x0032eda8 ***
Internal symbol error: unable to access memory location 0x32eda8)
[/home/chris/Programs/mesa/src/gallium/state_trackers/dri/drm/dri2.c:60] in
r300_dri.so (0x0032edc0)
  1 0x7e9542fb dri2InvalidateBuffers+0x2a(dpy=*** Invalid address 0x0032edc8
***
Internal symbol error: unable to access memory location 0x32edc8, drawable=***
Invalid address 0x0032edcc ***
) [/home/chris/Programs/mesa/src/glx/dri2_glx.c:678] in libgl.so.1 (0x0032ee00)
  2 0x7e95496f DRI2WireToEvent+0x11e(dpy=*** Invalid address 0x0032ee08 ***
Internal symbol error: unable to access memory location 0x32ee08, event=***
Invalid address 0x0032ee0c ***
Internal symbol error: unable to access memory location 0x32ee0c, wire=***
Invalid address 0x0032ee10 ***
Internal symbol error: unable to access memory location 0x32ee10)
[/home/chris/Programs/mesa/src/glx/dri2.c:136] in libgl.so.1 (0x0032ee40)
  3 0x7e9a9dd1 _XEnq+0x60() in libx11.so.6 (0x0032ee90)
  4 0x7e9b0a64 in libx11.so.6 (+0x42a63) (0x0032eeb0)
  5 0x7e9b10f8 _XEventsQueued+0x67() in libx11.so.6 (0x0032eed0)
  6 0x7e9b119a _XFlush+0x49() in libx11.so.6 (0x0032eef0)
  7 0x7e988eb2 XFlush+0x31() in libx11.so.6 (0x0032f000)
  8 0x7dd7087a X11DRV_WindowPosChanged+0x199() in winex11 (0x0032f100)
  9 0x7ed2ff32 USER_SetWindowPos+0x6e1() in user32 (0x0032f240)
  10 0x7ed2f2d7 SetWindowPos+0xa6() in user32 (0x0032f2c0)
  11 0x7ed30e95 WINPOS_ShowIconTitle+0xf4() in user32 (0x0032f310)
  12 0x7ed31bd4 show_window+0x513() in user32 (0x0032f390)
  13 0x7ed31cdb ShowWindow+0x6a() in user32 (0x0032f3c0)
  14 0x007b2651 in wow (+0x3b2650) (0x0032f3d4)
  15 0x007b1008 in wow (+0x3b1007) (0x0032f444)
  16 0x7ed33e1a WINPROC_wrapper+0x19() in user32 (0x0032f474)
  17 0x7ed3456c call_window_proc+0x5b() in user32 (0x0032f4c4)
  18 0x7ed351fc WINPROC_CallProcWtoA+0x90b() in user32 (0x0032fb54)

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

[PATCH] check_patch.pl: fix spaces

[Toralf Förster]

Signed-off-by: Toralf F?rster 
---
 drivers/gpu/drm/i915/i915_debugfs.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1f4f3ce..7232fcd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -244,13 +244,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
void *data)

if (work->old_fb_obj) {
struct drm_i915_gem_object *obj_priv = 
to_intel_bo(work->old_fb_obj);
-   if(obj_priv)
-   seq_printf(m, "Old framebuffer 
gtt_offset 0x%08x\n", obj_priv->gtt_offset );
+   if (obj_priv)
+   seq_printf(m, "Old framebuffer 
gtt_offset 0x%08x\n", obj_priv->gtt_offset);
}
if (work->pending_flip_obj) {
struct drm_i915_gem_object *obj_priv = 
to_intel_bo(work->pending_flip_obj);
-   if(obj_priv)
-   seq_printf(m, "New framebuffer 
gtt_offset 0x%08x\n", obj_priv->gtt_offset );
+   if (obj_priv)
+   seq_printf(m, "New framebuffer 
gtt_offset 0x%08x\n", obj_priv->gtt_offset);
}
}
spin_unlock_irqrestore(>event_lock, flags);
-- 
1.7.2.2

[stable] [PATCH] drm/kms: remove spaces from connector names

[Sergej Pupykin]

At Thu, 9 Dec 2010 09:18:14 -0800,
Jesse Barnes  wrote:
> 
> And it's ugly; can't we fix grub instead?

I am searching for bootloader which can pass whitespaces. It looks
like we should patch grub-legacy (0.97), grub (1.98) and lilo...

(I did not try lilo yet, but man page says nothing about passing
spaces in 'append=' option description)

[PATCH] drm-vblank: Always return true vblank count of scheduled vblank event.

[Jesse Barnes]

On Fri, 10 Dec 2010 16:00:19 +0100
Mario Kleiner  wrote:

> 
> 
>  Original Message 
> Subject: [PATCH] drm-vblank: Always return true vblank count of 
> scheduled vblank event.
> Date: Fri, 10 Dec 2010 15:58:10 +0100
> From: Mario Kleiner 
> To: airlied at gmail.com
> CC: jbarnes at virtuousgeek.org,  krh at bitplanet.net,   Mario Kleiner 
> 
> 
> This patch tries to make sure that the vbl.reply.sequence
> vblank count for a queued or emitted vblank event always
> corresponds to the true vblank count of queueing/emission, so
> the ddx can rely on the returned target_msc for consistency
> checks and implementation of swap_intervals in glXSwapBuffers().
> 
> Without this there is a small race-condition between the
> userspace ddx queueing a vblank event and the vblank
> counter incrementing before the event gets queued in
> the kernel.
> 
> Signed-off-by: Mario Kleiner 
> ---
>   drivers/gpu/drm/drm_irq.c |3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 4e82d0d..55160d7 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1086,15 +1086,18 @@ static int drm_queue_vblank_event(struct 
> drm_device *dev, int pipe,
> 
>   e->event.sequence = vblwait->request.sequence;
>   if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> + e->event.sequence = seq;
>   e->event.tv_sec = now.tv_sec;
>   e->event.tv_usec = now.tv_usec;
>   drm_vblank_put(dev, e->pipe);
>   list_add_tail(>base.link, >base.file_priv->event_list);
>   wake_up_interruptible(>base.file_priv->event_wait);
> + vblwait->reply.sequence = seq;
>   trace_drm_vblank_event_delivered(current->pid, pipe,
>vblwait->request.sequence);

But this actually causes us to return the current count rather than the
requested count if the event requested is in the past, right?

>   } else {
>   list_add_tail(>base.link, >vblank_event_list);
> + vblwait->reply.sequence = vblwait->request.sequence;
>   }

This one makes sense; we want to make sure the returned sequence is the
one requested (assuming it was in the future at the time of the request
anyway).

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 30616] r600g glitching in tunnel demo

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

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

--- Comment #9 from Andy Furniss  2010-12-10 
10:05:10 PST ---
(In reply to comment #8)
> the assert should give a bigger message, like a trace please paste it here

It doesn't give a trace  - running the binary direct just gives

Trace/breakpoint trap

I've tried gdb but it doesn't assert when running under it.

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

[stable] [PATCH] drm/kms: remove spaces from connector names

[Peter Stuge]

Sergej Pupykin wrote:
> > And it's ugly; can't we fix grub instead?
> 
> I am searching for bootloader which can pass whitespaces. It looks
> like we should patch grub-legacy (0.97), grub (1.98) and lilo...
> 
> (I did not try lilo yet, but man page says nothing about passing
> spaces in 'append=' option description)

append can contain any arbitrary string, which will be parsed by the
kernel. I e.g. use:

append="root=/dev/sda2 snd_ac97_codec.power_save=1 usbcore.autosuspend=1 
hpet=force quiet drm_kms_helper.poll=0"

And grub also supports an append string with spaces, that is probably
used by every distribution.

The question is, what will the kernel parser do about that space?


//Peter

[Bug 30616] r600g glitching in tunnel demo

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

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

--- Comment #10 from Andy Furniss  2010-12-10 
11:26:49 PST ---
(In reply to comment #9)

> I've tried gdb but it doesn't assert when running under it.

Sauerbraten is also affected, whatever perf is set to.
It also works with gdb -  


../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described:
Assertion `pipe_is_referenced(reference)' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb72746d0 (LWP 7870)]
_debug_assert_fail (expr=0xb65b2b3f "pipe_is_referenced(reference)",
file=0xb65b4fec "../../../../../src/gallium/auxiliary/util/u_inlines.h",
line=81, function=0xb65b9555 "pipe_reference_described") at util/u_debug.c:237
237 }
(gdb) bt
#0  _debug_assert_fail (expr=0xb65b2b3f "pipe_is_referenced(reference)",
file=0xb65b4fec "../../../../../src/gallium/auxiliary/util/u_inlines.h",
line=81, function=0xb65b9555 "pipe_reference_described") at util/u_debug.c:237
#1  0xb63a533a in r600_bo_reference (radeon=0x8823678, dst=0x8b13dec,
src=0xe47de78) at ../../../../../src/gallium/auxiliary/util/u_inlines.h:81
#2  0xb63a8570 in r600_context_pipe_state_set_fs_resource (ctx=0x8838ad0,
state=0xb62bb810, rid=1) at r600_hw_context.c:878
#3  0xb63853b1 in r600_vertex_buffer_update (rctx=0x8838948) at
r600_state.c:201
#4  0xb63965ef in r600_bind_vertex_elements (ctx=0x8838948, state=0x8b3f118) at
r600_state_common.c:129
#5  0xb656da57 in util_blitter_clear (blitter=0x8b3aad8, width=1024,
height=768, num_cbufs=1, clear_buffers=, rgba=0x8b4551c,
depth=1, stencil=0) at util/u_blitter.c:693
#6  0xb6399773 in r600_clear (ctx=0x8838948, buffers=1, rgba=0x8b4551c,
depth=1, stencil=0) at r600_blit.c:122
#7  0xb6506368 in st_Clear (ctx=0x8b44810, mask=2) at
state_tracker/st_cb_clear.c:550
#8  0xb64bc65a in _mesa_Clear (mask=16384) at main/clear.c:241
#9  0x08082abe in ?? ()
#10 0x0815f7be in ?? ()
#11 0x0818fdfd in ?? ()
#12 0x08194bf3 in ?? ()
#13 0x0805c49e in ?? ()
#14 0x0812d1bc in ?? ()
#15 0x0812dafd in ?? ()
#16 0x0819a333 in ?? ()
#17 0x0812e116 in ?? ()
#18 0x0805ca6a in ?? ()
#19 0x0818b2c5 in ?? ()
#20 0x0808486a in ?? ()
#21 0xb73ef380 in __libc_start_main () from /lib/libc.so.6
#22 0x0804c791 in ?? ()

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

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

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

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

--- Comment #3 from Ian Romanick  2010-12-10 13:42:47 
PST ---
(In reply to comment #2)
> I wonder if lowering DDX/DDY to SFL makes any difference compared to using a
> shader that outputs (0,0,0,1).

The lowering pass I was referring to would happen long before the Mesa IR
level.  At that point there is no SFL instruction.  We'd just replace the
ir_unop_dFdx and ir_unop_dFdy expressions with constants of 0 in the
appropriate type.  Backends (e.g., ir_to_mesa) can convert these constants to
whatever is appropriate.  This way backends for GPUs that can't handle these
operations will never even see them.  That is, after all, the whole point of
the various lowering passes in the GLSL compiler. :)

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

[Bug 32307] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting

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

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

   Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting
   Product: DRI
   Version: XOrg 6.7.0
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: gmalazdrewicz at gmail.com


Created an attachment (id=40995)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=40995)
ATI HD5850 BIOS

Similar to 32066, separate because it is a different card, and the BIOS is
stuck in a different place.

2.6.37~rc5
gerardo at envy17:~$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Broadway PRO [Mobility
Radeon HD 5800 Series]


[  286.000608] PM: Restoring platform NVS memory
[  286.949320] PM: early resume of devices complete after 1.683 msecs
[  286.950283] r8169 :03:00.0: PME# disabled
[  292.103312] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[  292.103316] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CECA (len 67, WS 0, PS 0) @ 0xCEF9
[  348.132820] PM: resume of devices complete after 61227.467 msecs
[  348.156549] PM: Finishing wakeup.

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

[Bug 32240] Second Life crashes on starting ( Linux 32-bit )

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

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

Ian Romanick  changed:

   What|Removed |Added

  Component|Drivers/DRI/r300|glsl-compiler
 AssignedTo|dri-devel at lists.freedesktop |idr at freedesktop.org
   |.org|

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

Intel DRM driver for SNB

[Segovia, Benjamin]

Thanks for the answer

I actually have no a rather simple prototype doing shared memory between CPU 
and GPU. Basically:
1/ I create a buffer B
2/ I map B and get a pointer to it
3/ I exec a batch buffer with B still mapped (ugly) and B pointed via a surface 
state internally 
4/ CPU and GPU are communicating throught B

To make things cleaner, I would like to let a non-root user pin the buffer in 
GTT (so change the ioctl rights) and write one more ioctl to make the CPU pages 
unevictable in shmfs (if I am right)

I would like to write an external module on top of i915 for these two 
functions. However, I am not sure I can get symbols from i915 properly. Is a 
i915 patch the only solution? 

Cheers,
Ben


From: Zhenyu Wang [zhen...@linux.intel.com]
Sent: Monday, December 06, 2010 11:00 PM
To: Segovia, Benjamin
Cc: DRI
Subject: Re: Intel DRM driver for SNB

On 2010.12.06 15:18:02 -0800, Segovia, Benjamin wrote:
> Hello all,
> is the kernel driver configured to support reads/writes to LLC (last level 
> cache i.e. L3) on SNB?

Now it's under limited use for the buffer that is sure to be cached,
e.g hw status page, etc. code lives in drivers/char/agp/intel-gtt.c.

--
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[Bug 32312] New: openvg "lion" demo freezes the system & lockup GPU with r600g

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

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

   Summary: openvg "lion" demo freezes the system & lockup GPU
with r600g
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: virtuousfox at gmail.com


in time of bug #30684 r600g were giving poor performance with "lion" demo
(about ~30 fps on my system) but not long ago i've noticed big, x10 time
speedup (up to ~350 fps). however, it was not for long: with
783e7caadf945f176cb297b8791769e2855fc9ef revision launching "lion" demo on my
system results in
1) video system freeze
2) 100% CPU time usage on all cores and total system freeze up if i not act
quickly and not kill demo process via ssh fast

if killed in time - all goes back to normal, in exception of
launching gles1gears demo right after which results in same behaviour.
however, repeated launch of gles1gears results in working demo but with some
artefacts.
third launch is all ok.

i'm pretty sure that regression was introduced in r600g in last 48 ~hours (same
revision but with r300g work ok) but i haven't done bisect.

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

[Bug 32312] openvg "lion" demo freezes the system & lockup GPU with r600g

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

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

--- Comment #1 from Sergey Kondakov  2010-12-10 
20:45:37 PST ---
Created an attachment (id=41000)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41000)
dmesg lockup info

all lockup info from dmesg.

there is also drm initialization info:
[0.319258] [drm] Initialized drm 1.1.0 20060810
[0.319366] [drm] radeon defaulting to kernel modesetting.
[0.319422] [drm] radeon kernel modesetting enabled.
[0.322089] [drm] initializing kernel modesetting (RV770 0x1002:0x944E).
[0.322209] [drm] register mmio base: 0xFDFE
[0.322263] [drm] register mmio size: 65536
[0.323107] [drm] Detected VRAM RAM=512M, BAR=256M
[0.323170] [drm] RAM width 128bits DDR
[0.323424] [drm] radeon: 512M of VRAM memory ready
[0.323479] [drm] radeon: 512M of GTT memory ready.
[0.323658] [drm] radeon: irq initialized.
[0.323713] [drm] GART: num cpu pages 131072, num gpu pages 131072
[0.325293] [drm] Loading RV770 Microcode
[0.373514] [drm] ring test succeeded in 1 usecs
[0.373681] [drm] radeon: ib pool ready.
[0.373759] [drm] ib test succeeded in 0 usecs
[0.373816] [drm] Enabling audio support
[0.374567] [drm] Radeon Display Connectors
[0.374623] [drm] Connector 0:
[0.374676] [drm]   DVI-I
[0.374730] [drm]   HPD2
[0.374784] [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c
0x7e6c
[0.374843] [drm]   Encoders:
[0.375863] [drm] DFP1: INTERNAL_UNIPHY
[0.375918] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[0.375972] [drm] Connector 1:
[0.376032] [drm]   DIN
[0.376085] [drm]   Encoders:
[0.376138] [drm] TV1: INTERNAL_KLDSCP_DAC2
[0.376192] [drm] Connector 2:
[0.376246] [drm]   DVI-I
[0.376298] [drm]   HPD1
[0.376352] [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c
0x7e2c
[0.376411] [drm]   Encoders:
[0.376464] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[0.376518] [drm] DFP2: INTERNAL_KLDSCP_LVTMA
[0.432622] [drm] Internal thermal controller without fan control
[0.432755] [drm] radeon: power management initialized
[0.517044] [drm] fb mappable at 0xD0142000
[0.517099] [drm] vram apper at 0xD000
[0.517153] [drm] size 8294400
[0.517207] [drm] fb depth is 24
[0.517260] [drm]pitch is 7680
[0.517405] fbcon: radeondrmfb (fb0) is primary device
[0.931659] fb0: radeondrmfb frame buffer device
[0.931690] drm: registered panic notifier
[0.931721] [drm] Initialized radeon 2.7.0 20080528 for :01:00.0 on
minor 0

and, by the way, color tiling is enabled and forced-on in X but i doubt is has
anything to do with it.

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