date:20130530

[Bug 64983] X3 Terran Conflict displays strange colors.

2013-05-30 Thread bugzilla-daemon

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

Knut Andre Tidemann  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Knut Andre Tidemann  ---
Egosoft released a update to X3:TC yesterday and the corruption is now gone.
Closing as an appliaction bug.

-- 
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 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

2013-05-30 Thread bugzilla-daemon

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

--- Comment #9 from Michel Dänzer  ---
(In reply to comment #8)
> (no rure to generate the «../../../src/mapi/entry.c», necessary for
> «entry.lo».  Stop.

That should only happen when switching between the master and 9.1 branches. In
that case, the easiest solution is to make distclean and start from scratch.

-- 
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: [PATCH] drm/i915: no lvds quirk for hp t5740

2013-05-30 Thread Ben Mesman (Bossers & Cnossen BV)

Hello,

Did anyone pick up this patch? Or is there a problem with it?

Thanks,
Ben Mesman.

> -Oorspronkelijk bericht-
> Van: Ben Mesman [mailto:b...@bnc.nl]
> Verzonden: dinsdag 16 april 2013 20:00
> Aan: Daniel Vetter
> CC: dri-devel@lists.freedesktop.org; Ben Mesman (Bossers & Cnossen BV)
> Onderwerp: [PATCH] drm/i915: no lvds quirk for hp t5740
> 
> Last year, a patch was made for the "HP t5740e Thin Client" (see
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> This device reports an lvds panel, but does not really have one.
> 
> The predecessor of this device is the "hp t5740", which also does not have an
> lvds panel. This patch will add the same quirk for this device.
> 
> Signed-off-by: Ben Mesman 
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index ca2d903..5df079c 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -816,10 +816,10 @@ static const struct dmi_system_id intel_no_lvds[] =
> {
>   },
>   {
>   .callback = intel_no_lvds_dmi_callback,
> - .ident = "Hewlett-Packard HP t5740e Thin Client",
> + .ident = "Hewlett-Packard HP t5740",
>   .matches = {
>   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-
> Packard"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin
> Client"),
> + DMI_MATCH(DMI_PRODUCT_NAME, " t5740"),
>   },
>   },
>   {
> --
> 1.7.10.4

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

Re: [PATCH] drm/i915: no lvds quirk for hp t5740

2013-05-30 Thread Daniel Vetter

On Thu, May 30, 2013 at 07:32:36AM +, Ben Mesman (Bossers & Cnossen BV) 
wrote:
> Hello,
> 
> Did anyone pick up this patch? Or is there a problem with it?

Oops, slipped through the cracks, my apologies. Picked up for -fixes,
thanks for the patch.
-Daniel

> 
> Thanks,
> Ben Mesman.
> 
> > -Oorspronkelijk bericht-
> > Van: Ben Mesman [mailto:b...@bnc.nl]
> > Verzonden: dinsdag 16 april 2013 20:00
> > Aan: Daniel Vetter
> > CC: dri-devel@lists.freedesktop.org; Ben Mesman (Bossers & Cnossen BV)
> > Onderwerp: [PATCH] drm/i915: no lvds quirk for hp t5740
> > 
> > Last year, a patch was made for the "HP t5740e Thin Client" (see
> > http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> > This device reports an lvds panel, but does not really have one.
> > 
> > The predecessor of this device is the "hp t5740", which also does not have 
> > an
> > lvds panel. This patch will add the same quirk for this device.
> > 
> > Signed-off-by: Ben Mesman 
> > ---
> >  drivers/gpu/drm/i915/intel_lvds.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index ca2d903..5df079c 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -816,10 +816,10 @@ static const struct dmi_system_id intel_no_lvds[] =
> > {
> > },
> > {
> > .callback = intel_no_lvds_dmi_callback,
> > -   .ident = "Hewlett-Packard HP t5740e Thin Client",
> > +   .ident = "Hewlett-Packard HP t5740",
> > .matches = {
> > DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-
> > Packard"),
> > -   DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin
> > Client"),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, " t5740"),
> > },
> > },
> > {
> > --
> > 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-30 Thread bugzilla-daemon

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

--- Comment #27 from Andy Furniss  ---
(In reply to comment #23)
> What is the revision of llvm ?
> You may try this patch :
> http://cgit.freedesktop.org/~vlj/llvm/commit/
> ?h=textures&id=5e9129b7626738ff3cc539cc30f28536cd9d5662

fixes the regression caused by -

commit 061ff3409d4f6db313448fa8d916313233789516

so most things work on rv770.

Heaven is still wrong, though.

-- 
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: [PATCH v4 2/4] mutex: add support for wound/wait style locks, v5

2013-05-30 Thread Maarten Lankhorst

Op 29-05-13 12:33, Inki Dae schreef:
> Hi,
>
> Just minor comments
>
> +Usage
>> +-
>> +
>> +Three different ways to acquire locks within the same w/w class. Common
>> +definitions for methods #1 and #2:
>> +
>> +static DEFINE_WW_CLASS(ww_class);
>> +
>> +struct obj {
>> +   struct ww_mutex lock;
>> +   /* obj data */
>> +};
>> +
>> +struct obj_entry {
>> +   struct list_head *list;
>> +   struct obj *obj;
>> +};
>> +
>> +Method 1, using a list in execbuf->buffers that's not allowed to be
>> reordered.
>> +This is useful if a list of required objects is already tracked somewhere.
>> +Furthermore the lock helper can use propagate the -EALREADY return code
>> back to
>> +the caller as a signal that an object is twice on the list. This is
>> useful if
>> +the list is constructed from userspace input and the ABI requires
>> userspace to
>> +not have duplicate entries (e.g. for a gpu commandbuffer submission
>> ioctl).
>> +
>> +int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
>> +{
>> +   struct obj *res_obj = NULL;
>> +   struct obj_entry *contended_entry = NULL;
>> +   struct obj_entry *entry;
>> +
>> +   ww_acquire_init(ctx, &ww_class);
>> +
>> +retry:
>> +   list_for_each_entry (list, entry) {
>> +   if (entry == res_obj) {
>>
Indeed, documentation was wrong. With the below diff it should almost compile 
now.
I really don't want to know if it really does, it's meant to be documentation!

diff --git a/Documentation/ww-mutex-design.txt 
b/Documentation/ww-mutex-design.txt
index 8bd1761..379739c 100644
--- a/Documentation/ww-mutex-design.txt
+++ b/Documentation/ww-mutex-design.txt
@@ -100,7 +100,7 @@ struct obj {
 };
 
 struct obj_entry {
-   struct list_head *list;
+   struct list_head head;
struct obj *obj;
 };
 
@@ -120,14 +120,14 @@ int lock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)
ww_acquire_init(ctx, &ww_class);
 
 retry:
-   list_for_each_entry (list, entry) {
-   if (entry == res_obj) {
+   list_for_each_entry (entry, list, head) {
+   if (entry->obj == res_obj) {
res_obj = NULL;
continue;
}
ret = ww_mutex_lock(&entry->obj->lock, ctx);
if (ret < 0) {
-   contended_obj = entry;
+   contended_entry = entry;
goto err;
}
}
@@ -136,7 +136,7 @@ retry:
return 0;
 
 err:
-   list_for_each_entry_continue_reverse (list, contended_entry, entry)
+   list_for_each_entry_continue_reverse (entry, list, head)
ww_mutex_unlock(&entry->obj->lock);
 
if (res_obj)
@@ -163,13 +163,13 @@ int lock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)
 
ww_acquire_init(ctx, &ww_class);
 
-   list_for_each_entry (list, entry) {
+   list_for_each_entry (entry, list, head) {
ret = ww_mutex_lock(&entry->obj->lock, ctx);
if (ret < 0) {
entry2 = entry;
 
-   list_for_each_entry_continue_reverse (list, entry2)
-   ww_mutex_unlock(&entry->obj->lock);
+   list_for_each_entry_continue_reverse (entry2, list, 
head)
+   ww_mutex_unlock(&entry2->obj->lock);
 
if (ret != -EDEADLK) {
ww_acquire_fini(ctx);
@@ -184,8 +184,8 @@ int lock_objs(struct list_head *list, struct ww_acquire_ctx 
*ctx)
 * buf->next to the first unlocked entry,
 * restarting the for loop.
 */
-   list_del(&entry->list);
-   list_add(&entry->list, list);
+   list_del(&entry->head);
+   list_add(&entry->head, list);
}
}
 
@@ -199,7 +199,7 @@ void unlock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)
 {
struct obj_entry *entry;
 
-   list_for_each_entry (list, entry)
+   list_for_each_entry (entry, list, head)
ww_mutex_unlock(&entry->obj->lock);
 
ww_acquire_fini(ctx);
@@ -244,22 +244,21 @@ struct obj {
 
 static DEFINE_WW_CLASS(ww_class);
 
-void __unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+void __unlock_objs(struct list_head *list)
 {
-   struct obj entry;
+   struct obj *entry, *temp;
 
-   for_each_safe (list, entry) {
+   list_for_each_entry_safe (entry, temp, list, locked_list) {
/* need to do that before unlocking, since only the current 
lock holder is
allowed to use object */
-   list_del(entry->locked_list);
+   list_del(&entry->locked_list);
ww_mutex_unlock(entry->ww_mutex)
}
 }
 
 void lock_objs(struct list_head *list, struct ww_acquire_ctx

[Bug 65190] New: glxgears on r600g (rv770) is garbled with llvm enabled

2013-05-30 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 65190
  Assignee: dri-devel@lists.freedesktop.org
   Summary: glxgears on r600g (rv770) is garbled with llvm enabled
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: a...@sannes.org
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 80067
  --> https://bugs.freedesktop.org/attachment.cgi?id=80067&action=edit
output of R600-DEBUG=vs,ps glxgears

Running glxgears gives garbled output, tstellar on irc asked me to file a bug
with the output of R600_DEBUG=vs,ps glxgears

I have a rv770 card (4870) and have compiled mesa with llvm.

It does not get garbled if I run with:

R600_DEBUG=sb works.

-- 
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 65190] glxgears on r600g (rv770) is garbled with llvm enabled

2013-05-30 Thread bugzilla-daemon

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

Asbjørn Sannes  changed:

   What|Removed |Added

  Attachment #80067|0   |1
is obsolete||

--- Comment #1 from Asbjørn Sannes  ---
Created attachment 80068
  --> https://bugs.freedesktop.org/attachment.cgi?id=80068&action=edit
output of R600-DEBUG=vs,ps glxgears

-- 
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 58901] "trying to bind memory to uninitialized GART" error at resume from suspend to memory

2013-05-30 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=58901





--- Comment #2 from Christian Casteyde   2013-05-30 
20:47:54 ---
No I don't think so, because it is too difficult to reproduce these times.
I wonder if suspending while playing a video helps.
It hasn't appear this week at all for instance (the warning I reported was from
last week).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

2013-05-30 Thread bugzilla-daemon

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

--- Comment #10 from mombelli.ma...@gmail.com ---
Yeh, got it, I've tryed to compile from master, then from other tag
thinking git checkout woul clear everything. My bad, I'll try to compile
again when I can. Should I use newer tag than 1.1?
I think strage that compiling mAster was on error for me.. Normally aren't
the pull self-contined?
Il giorno 30/mag/2013 09:16,  ha scritto:

>   *Comment # 9  on bug
> 64776  from Michel
> Dänzer  *
>
> (In reply to comment #8 
> )> (no rure to 
> generate the «../../../src/mapi/entry.c», necessary for
> > «entry.lo».  Stop.
>
> That should only happen when switching between the master and 9.1 branches. In
> that case, the easiest solution is to make distclean and start from scratch.
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

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

X.org's GSoC 2013 projects

2013-05-30 Thread Martin Peres


Hi everyone,

On Monday, GSoC students were informed about which projects were selected to
participate in the program. Here is a short overview of the students who 
have been

selected to work with the X.org foundation:

== DRM Render/Modeset Nodes ==
Student: David Herrmann
Mentor: Dave Airlie (airlied)
Blog: http://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/

== Add Xv support to Glamor ==
Student: Chuan He
Mentors: Arthur Huillet (ahuillet) & Alex Deucher (agd5f)
Blog: http://bigchuan.xanga.com/

== Reverse engineering NVidia's performance counters and exposing them 
via nv_perfmon ==

Student: Samuel Pitoiset (hakzsam)
Mentor: Martin Peres (mupuf)
Blog: http://hakzsam.wordpress.com/ 

== Implementing GL_EXT_direct_state_access ==
Student: Dylan Noblesmith
Mentor: Ian Romanick
Proposal: 
http://www.cs.usm.maine.edu/~noblesmith/gsoc2013proposal-ext-direct-state-access.txt


On a related note, Francisco Jerez (curro) has also been accepted to 
work on a TGSI
backend for LLVM, mentored by Tom Stellar (tstellar). This effort will 
likely bring support
for openCL to Nouveau and could also bring support to r300g, freedreno, 
etc...

Proposal: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060917.html

The project list looks pretty interesting, I hope the results will be 
just as good :)


Martin (AKA mupuf)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65192] New: Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 65192
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Screensavers lock up machine (screen goes blank,
keyboard unresponsive, sound loops; sysrq/ssh
possible)
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: luziphermcl...@yahoo.ie
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

For a while now, some screensavers sometimes lock up my machine. That means all
screens go blank, the keyboard is unresponsive (numpad-key doesn't toggle the
indicator led), the sound loops. But I still can use ssh from a remote machine
and the magic-sysrq-keys also work.

There is nothing to see in neither /var/log/messages (acquired via netconsole)
nor /var/log/Xorg.0.log.

I can trigger the bug (or regression, I think it used to work about 2 months
ago) reliably by using the Xfce4 screensaver settings application, which has a
preview of the screensaver selected. When switching between screensavers, the
lockup quickly occurs. A good candidate is the screensaver named "AntMaze", it
alsmost always locks up my machine (only worked once so far).
Other stuff works quite solid, Half-Life 2 worked multiple hours today.

Setting R600_HYPERZ=0 in /etc/environment didn't help. Also occurs on kernel
3.8.0-rc7.

I'm happy to provide more info if needed.



System Specs:
Intel Core i7-965
2x Radeon HD4870 (rv770, currently only one active without xorg.conf), 2
Monitors

Gentoo Linux
Kernel 3.10.0-rc3
Mesa 9.2.0 (git-60f9b72) git commit 60f9b722ef80c499a94b4e5ab7304dcd739ea569
Revert "i965: fix problem with constant out of bounds access (v2)"
xorg-server-1.14.1
libdrm git commit 8a88e349975a64676f143183e835e6d296f29627 modetest: Make
RGB565 pwetty too
xf86-video-ati git commit commit bd2557ea5ef84b975060e929d5ece53ec464336f DRI2:
add interpolated blanks to frame number in event handlers

-- 
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 65192] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-daemon

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

--- Comment #1 from Luzipher  ---
I forgot to mention: I use the classic shader compiler at the moment and I have
egl, gles1, gles2, vdpau and wayland enabled.

Full flags on portage:
[ebuild   R   #] media-libs/mesa-::x11  USE="egl gallium gles1 gles2 llvm
nptl shared-glapi vdpau wayland -abiwrapper -bindist -classic -debug -gbm
-opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -xa
-xorg -xvmc" MULTILIB_ABI="amd64 x86" PYTHON_SINGLE_TARGET="python2_7
-python2_6" PYTHON_TARGETS="python2_7 -python2_6" VIDEO_CARDS="r600
(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -radeon
-radeonsi -vmware"

-- 
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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-daemon

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

Luzipher  changed:

   What|Removed |Added

Summary|Screensavers lock up|[r600g] Screensavers lock
   |machine (screen goes blank, |up machine (screen goes
   |keyboard unresponsive,  |blank, keyboard
   |sound loops; sysrq/ssh  |unresponsive, sound loops;
   |possible)   |sysrq/ssh possible)

-- 
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 65193] New: [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 65193
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [bisected] r600g, can't launch Gnome Shell and KDE
since mesa updated to
5de41575a127eb8a6a0fe5c71a73b372f9b89f53
  Severity: critical
Classification: Unclassified
OS: All
  Reporter: alexandre.f.dem...@gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

I haven't been able to log in Gnome Shell or KDE lately since I updated mesa
from git. Using XFCE and doing some tests, I've found out glxgears returns an
assertion error when launch. glxgears fails with the following error:
sb/sb_expr.cpp:455:fold_alu_op2: Assertion `v0 && v1 && n.dst[0]' failed.
line 6: 15521 Trace/breakpoint trap   (core dumped) $1

Bisecting ended up point to culprit commit:
commit 5de41575a127eb8a6a0fe5c71a73b372f9b89f53
Author: Vadim Girlin 
Date:   Mon May 27 14:23:47 2013 +0400

r600g/sb: improve folding for SETcc

Signed-off-by: Vadim Girlin 

:04 04 96a6fd8851d84f62896ecfba6c4a7df5a7963325
ade9a1e6d7fd56ed8cf413a2138c38011f1b9827 Msrc


Using latest drm, ddx from git on a Radeon HD6950 Cayman.

-- 
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 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-daemon

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] r600g, can't |[bisected] r600g, can't
   |launch Gnome Shell and KDE  |launch glxgears since mesa
   |since mesa updated to   |updated to
   |5de41575a127eb8a6a0fe5c71a7 |5de41575a127eb8a6a0fe5c71a7
   |3b372f9b89f53   |3b372f9b89f53

-- 
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 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-daemon

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

--- Comment #1 from Alexandre Demers  ---
It seems the identified failed assertion is not the prime root of Gnome Shell
and KDE not launching. A previous commit must be the culprit for the other
problem (I'm tracking it down right now). However, commit
5de41575a127eb8a6a0fe5c71a73b372f9b89f53 does prevent glxgears from running as
it should.

-- 
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 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-daemon

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

--- Comment #2 from Alexandre Demers  ---
(In reply to comment #1)
> It seems the identified failed assertion is not the prime root of Gnome
> Shell and KDE not launching. A previous commit must be the culprit for the
> other problem (I'm tracking it down right now). However, commit
> 5de41575a127eb8a6a0fe5c71a73b372f9b89f53 does prevent glxgears from running
> as it should.

Forget about what I just said, I made a mistake, wrongly resync before last
build. Retesting right away.

-- 
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 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-daemon

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] r600g, can't |[bisected] r600g, can't
   |launch glxgears since mesa  |launch Gnome Shell and KDE
   |updated to  |since mesa updated to
   |5de41575a127eb8a6a0fe5c71a7 |5de41575a127eb8a6a0fe5c71a7
   |3b372f9b89f53   |3b372f9b89f53

--- Comment #3 from Alexandre Demers  ---
commit 5de41575a127eb8a6a0fe5c71a73b372f9b89f53 is really the first bad commit
preventing Gnome Shell and KDE from starting correctly (Gnome ends with a Oops
and KDE just fails and relaunches X).

-- 
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 54867] bug in r300 compiler

2013-05-30 Thread bugzilla-daemon

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

--- Comment #1 from Chistopher Krakowiak  ---
Created attachment 80074
  --> https://bugs.freedesktop.org/attachment.cgi?id=80074&action=edit
s/signed/int/

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

[git pull] drm fixes

2013-05-30 Thread Dave Airlie


Hi Linus,

one qxl 32-bit warning fix, the rest is a bunch of radeon fixes from Alex 
for some issues we've been seeing.

Dave.

The following changes since commit c89b65e7fffef745bdd36c372aa0dea778fecbab:

  qxl: fix Kconfig deps - select FB_DEFERRED_IO (2013-05-28 17:03:37 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 970fa986fadb1165cf38b45b70e98302a3bee497:

  drm/qxl: fix build warnings on 32-bit (2013-05-31 12:45:09 +1000)


Alex Deucher (4):
  drm/radeon: fix typo in cu_per_sh on verde
  drm/radeon: fix card_posted check for newer asics
  drm/radeon: don't check crtcs in card_posted() on cards without DCE
  drm/radeon: narrow scope of Apple re-POST hack

Christian König (1):
  drm/radeon: UVD block on SUMO2 is the same as on SUMO

Dave Airlie (2):
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-next
  drm/qxl: fix build warnings on 32-bit

Kleber Sacilotto de Souza (1):
  radeon: use max_bus_speed to activate gen2 speeds

 drivers/gpu/drm/qxl/qxl_ioctl.c|  4 ++--
 drivers/gpu/drm/qxl/qxl_kms.c  |  9 +
 drivers/gpu/drm/radeon/evergreen.c | 10 +++---
 drivers/gpu/drm/radeon/r600.c  |  9 ++---
 drivers/gpu/drm/radeon/radeon_device.c | 27 ---
 drivers/gpu/drm/radeon/rv770.c | 13 +++--
 drivers/gpu/drm/radeon/si.c|  2 +-
 7 files changed, 32 insertions(+), 42 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/9] Clean up write-combining MTRR addition

2013-05-30 Thread Dave Airlie

On Fri, May 24, 2013 at 4:35 AM, Andy Lutomirski  wrote:
> On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski  wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> need to use MTRRs.
>>
>> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
>> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
>> otherwise.  (Other architectures, if any, with a similar mechanism could
>> implement them.)
>
> That's the path to upstream for this?  Should it go through drm-next?
> (Sorry for possible noob question -- I've never sent in anything other
> than trivial fixes to drm stuff before.)

I've pulled the v3 series into drm-next, lets see how they go for a while,

I suppose I should try and boot an AGP box with them.

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

Re: [PATCH v3 3/9] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-30 Thread Dave Airlie

On Tue, May 14, 2013 at 9:58 AM, Andy Lutomirski  wrote:
> Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
> mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
> MTRR being added but the actual mappings being created as UC-.
>
> Now these mappings have the MTRR added only if needed, but they will
> be mapped with pgprot_writecombine.
>
> The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
> hardcoding the bit twiddling.
>
> The DRM_AGP case is unchanged for now.

Just FYI this breaks on powerpc build, I've fixed it up and pushed the
fixed version to
drm-next-staging, I'll push that to drm-next in a couple of days, once
kbuild robot hits it.

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

[PATCH] drm/radeon: restrict engine clock to fastest power state

2013-05-30 Thread Alan Swanson

Radeon power management restricts the maximum engine clock to the initial
default clock. However, on APUs the default clock usually is not the fastest
allowed by their defined power states. Change restriction to the fastest
engine clock found in power states.

Signed-off-by: Alan Swanson 
---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_pm.c | 25 ++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1442ce7..83d1e76 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -,6 +,7 @@ struct radeon_pm {
u32 default_mclk;
u16 default_vddc;
u16 default_vddci;
+   u32 max_sclk;
struct radeon_i2c_chan *i2c_bus;
/* selected pm method */
enum radeon_pm_method pm_method;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 788c64c..3512af9 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -164,8 +164,8 @@ static void radeon_set_power_state(struct radeon_device 
*rdev)
if (radeon_gui_idle(rdev)) {
sclk = 
rdev->pm.power_state[rdev->pm.requested_power_state_index].
clock_info[rdev->pm.requested_clock_mode_index].sclk;
-   if (sclk > rdev->pm.default_sclk)
-   sclk = rdev->pm.default_sclk;
+   if (sclk > rdev->pm.max_sclk)
+   sclk = rdev->pm.max_sclk;

/* starting with BTC, there is one state that is used for both
 * MH and SH.  Difference is that we always use the high clock 
index for
@@ -307,7 +307,7 @@ static void radeon_pm_print_states(struct radeon_device 
*rdev)
DRM_DEBUG_DRIVER("State %d: %s\n", i,
radeon_pm_state_type_name[power_state->type]);
if (i == rdev->pm.default_power_state_index)
-   DRM_DEBUG_DRIVER("\tDefault");
+   DRM_DEBUG_DRIVER("\tDEFAULT\n");
if ((rdev->flags & RADEON_IS_PCIE) && !(rdev->flags & 
RADEON_IS_IGP))
DRM_DEBUG_DRIVER("\t%d PCIE Lanes\n", 
power_state->pcie_lanes);
if (power_state->flags & RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
@@ -329,6 +329,22 @@ static void radeon_pm_print_states(struct radeon_device 
*rdev)
}
 }

+static void radeon_pm_get_max_clocks(struct radeon_device *rdev)
+{
+   int i, j;
+   struct radeon_power_state *power_state;
+   struct radeon_pm_clock_info *clock_info;
+
+   for (i = 0; i < rdev->pm.num_power_states; i++) {
+   power_state = &rdev->pm.power_state[i];
+   for (j = 0; j < power_state->num_clock_modes; j++) {
+   clock_info = &(power_state->clock_info[j]);
+   if (clock_info->sclk > rdev->pm.max_sclk)
+   rdev->pm.max_sclk = clock_info->sclk;
+   }
+   }
+}
+
 static ssize_t radeon_get_pm_profile(struct device *dev,
 struct device_attribute *attr,
 char *buf)
@@ -588,6 +604,7 @@ int radeon_pm_init(struct radeon_device *rdev)
rdev->pm.default_mclk = rdev->clock.default_mclk;
rdev->pm.current_sclk = rdev->clock.default_sclk;
rdev->pm.current_mclk = rdev->clock.default_mclk;
+   rdev->pm.max_sclk = rdev->clock.default_sclk;
rdev->pm.int_thermal_type = THERMAL_TYPE_NONE;

if (rdev->bios) {
@@ -597,6 +614,7 @@ int radeon_pm_init(struct radeon_device *rdev)
radeon_combios_get_power_modes(rdev);
radeon_pm_print_states(rdev);
radeon_pm_init_profile(rdev);
+   radeon_pm_get_max_clocks(rdev);
/* set up the default clocks if the MC ucode is loaded */
if ((rdev->family >= CHIP_BARTS) &&
(rdev->family <= CHIP_CAYMAN) &&
@@ -848,6 +866,7 @@ static int radeon_debugfs_pm_info(struct seq_file *m, void 
*data)
seq_printf(m, "current engine clock: %u0 kHz\n", 
rdev->pm.current_sclk);
else
seq_printf(m, "current engine clock: %u0 kHz\n", 
radeon_get_engine_clock(rdev));
+   seq_printf(m, "maximum engine clock: %u0 kHz\n", rdev->pm.max_sclk);
seq_printf(m, "default memory clock: %u0 kHz\n", rdev->pm.default_mclk);
if (rdev->asic->pm.get_memory_clock)
seq_printf(m, "current memory clock: %u0 kHz\n", 
radeon_get_memory_clock(rdev));
-- 
1.8.1.5

[Bug 64850] Second screen black on Pitcairn PRO

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #19 from akb825 at gmail.com ---
I have a Radeon 7870 and I have the same problem: the desktop extends as if
there are 2 monitors, but the second monitor is always black. I have both
monitors plugged into DVI ports (DVI-0 and DVI-1), and xrandr correctly
recognizes both monitors as being present as well as all of their display
modes, but whenever I try to change the display to one monitor or the other it
will only ever display on the monitor plugged into DVI-0.

When I go through the display settings tool in XFCE (which I'm assuming is just
a UI around xrandr) it correctly shows both monitors, but whenever I try to
adjust the second monitor's resolution or disable the second monitor it
completely corrupts the display (showing a striped pattern on the first
monitor, second monitor is still black) and the only way to recover is to
reboot. I can switch to a tty terminal and blindly type commands, but when I
attempted to shut down my display manager daemon and unload the radeon module
nothing happened, though since the display was corrupted I couldn't see if
either of the commands failed. Adjusting the resolution of the first monitor
works correctly.

One thing to note is whenever I start xorg, the following gets printed several
times to the error log:
May 29 20:27:31 localhost kernel: [  199.484959] radeon :02:00.0: bo
8801ad899400 don't has a mapping in vm 8801affc6980

I am also using 64-bit Arch Linux, running under kernel 3.9.4 and xorg 1.14.1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/baecebd2/attachment-0001.html>

[Bug 64983] X3 Terran Conflict displays strange colors.

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Knut Andre Tidemann  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Knut Andre Tidemann  ---
Egosoft released a update to X3:TC yesterday and the corruption is now gone.
Closing as an appliaction bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/b849693d/attachment.html>

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from Michel D?nzer  ---
(In reply to comment #8)
> (no rure to generate the ?../../../src/mapi/entry.c?, necessary for
> ?entry.lo?.  Stop.

That should only happen when switching between the master and 9.1 branches. In
that case, the easiest solution is to make distclean and start from scratch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/721181c3/attachment.html>

[PATCH] drm/i915: no lvds quirk for hp t5740

2013-05-30 Thread Ben Mesman (Bossers & Cnossen BV)

Hello,

Did anyone pick up this patch? Or is there a problem with it?

Thanks,
Ben Mesman.

> -Oorspronkelijk bericht-
> Van: Ben Mesman [mailto:ben at bnc.nl]
> Verzonden: dinsdag 16 april 2013 20:00
> Aan: Daniel Vetter
> CC: dri-devel at lists.freedesktop.org; Ben Mesman (Bossers & Cnossen BV)
> Onderwerp: [PATCH] drm/i915: no lvds quirk for hp t5740
> 
> Last year, a patch was made for the "HP t5740e Thin Client" (see
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> This device reports an lvds panel, but does not really have one.
> 
> The predecessor of this device is the "hp t5740", which also does not have an
> lvds panel. This patch will add the same quirk for this device.
> 
> Signed-off-by: Ben Mesman 
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index ca2d903..5df079c 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -816,10 +816,10 @@ static const struct dmi_system_id intel_no_lvds[] =
> {
>   },
>   {
>   .callback = intel_no_lvds_dmi_callback,
> - .ident = "Hewlett-Packard HP t5740e Thin Client",
> + .ident = "Hewlett-Packard HP t5740",
>   .matches = {
>   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-
> Packard"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin
> Client"),
> + DMI_MATCH(DMI_PRODUCT_NAME, " t5740"),
>   },
>   },
>   {
> --
> 1.7.10.4

[PATCH] drm/i915: no lvds quirk for hp t5740

2013-05-30 Thread Daniel Vetter

On Thu, May 30, 2013 at 07:32:36AM +, Ben Mesman (Bossers & Cnossen BV) 
wrote:
> Hello,
> 
> Did anyone pick up this patch? Or is there a problem with it?

Oops, slipped through the cracks, my apologies. Picked up for -fixes,
thanks for the patch.
-Daniel

> 
> Thanks,
> Ben Mesman.
> 
> > -Oorspronkelijk bericht-
> > Van: Ben Mesman [mailto:ben at bnc.nl]
> > Verzonden: dinsdag 16 april 2013 20:00
> > Aan: Daniel Vetter
> > CC: dri-devel at lists.freedesktop.org; Ben Mesman (Bossers & Cnossen BV)
> > Onderwerp: [PATCH] drm/i915: no lvds quirk for hp t5740
> > 
> > Last year, a patch was made for the "HP t5740e Thin Client" (see
> > http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> > This device reports an lvds panel, but does not really have one.
> > 
> > The predecessor of this device is the "hp t5740", which also does not have 
> > an
> > lvds panel. This patch will add the same quirk for this device.
> > 
> > Signed-off-by: Ben Mesman 
> > ---
> >  drivers/gpu/drm/i915/intel_lvds.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index ca2d903..5df079c 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -816,10 +816,10 @@ static const struct dmi_system_id intel_no_lvds[] =
> > {
> > },
> > {
> > .callback = intel_no_lvds_dmi_callback,
> > -   .ident = "Hewlett-Packard HP t5740e Thin Client",
> > +   .ident = "Hewlett-Packard HP t5740",
> > .matches = {
> > DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-
> > Packard"),
> > -   DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin
> > Client"),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, " t5740"),
> > },
> > },
> > {
> > --
> > 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #27 from Andy Furniss  ---
(In reply to comment #23)
> What is the revision of llvm ?
> You may try this patch :
> http://cgit.freedesktop.org/~vlj/llvm/commit/
> ?h=textures&id=5e9129b7626738ff3cc539cc30f28536cd9d5662

fixes the regression caused by -

commit 061ff3409d4f6db313448fa8d916313233789516

so most things work on rv770.

Heaven is still wrong, though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/ab5af0bd/attachment.html>

[PATCH v4 2/4] mutex: add support for wound/wait style locks, v5

2013-05-30 Thread Maarten Lankhorst

Op 29-05-13 12:33, Inki Dae schreef:
> Hi,
>
> Just minor comments
>
> +Usage
>> +-
>> +
>> +Three different ways to acquire locks within the same w/w class. Common
>> +definitions for methods #1 and #2:
>> +
>> +static DEFINE_WW_CLASS(ww_class);
>> +
>> +struct obj {
>> +   struct ww_mutex lock;
>> +   /* obj data */
>> +};
>> +
>> +struct obj_entry {
>> +   struct list_head *list;
>> +   struct obj *obj;
>> +};
>> +
>> +Method 1, using a list in execbuf->buffers that's not allowed to be
>> reordered.
>> +This is useful if a list of required objects is already tracked somewhere.
>> +Furthermore the lock helper can use propagate the -EALREADY return code
>> back to
>> +the caller as a signal that an object is twice on the list. This is
>> useful if
>> +the list is constructed from userspace input and the ABI requires
>> userspace to
>> +not have duplicate entries (e.g. for a gpu commandbuffer submission
>> ioctl).
>> +
>> +int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
>> +{
>> +   struct obj *res_obj = NULL;
>> +   struct obj_entry *contended_entry = NULL;
>> +   struct obj_entry *entry;
>> +
>> +   ww_acquire_init(ctx, &ww_class);
>> +
>> +retry:
>> +   list_for_each_entry (list, entry) {
>> +   if (entry == res_obj) {
>>
Indeed, documentation was wrong. With the below diff it should almost compile 
now.
I really don't want to know if it really does, it's meant to be documentation!

diff --git a/Documentation/ww-mutex-design.txt 
b/Documentation/ww-mutex-design.txt
index 8bd1761..379739c 100644
--- a/Documentation/ww-mutex-design.txt
+++ b/Documentation/ww-mutex-design.txt
@@ -100,7 +100,7 @@ struct obj {
 };

 struct obj_entry {
-   struct list_head *list;
+   struct list_head head;
struct obj *obj;
 };

@@ -120,14 +120,14 @@ int lock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)
ww_acquire_init(ctx, &ww_class);

 retry:
-   list_for_each_entry (list, entry) {
-   if (entry == res_obj) {
+   list_for_each_entry (entry, list, head) {
+   if (entry->obj == res_obj) {
res_obj = NULL;
continue;
}
ret = ww_mutex_lock(&entry->obj->lock, ctx);
if (ret < 0) {
-   contended_obj = entry;
+   contended_entry = entry;
goto err;
}
}
@@ -136,7 +136,7 @@ retry:
return 0;

 err:
-   list_for_each_entry_continue_reverse (list, contended_entry, entry)
+   list_for_each_entry_continue_reverse (entry, list, head)
ww_mutex_unlock(&entry->obj->lock);

if (res_obj)
@@ -163,13 +163,13 @@ int lock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)

ww_acquire_init(ctx, &ww_class);

-   list_for_each_entry (list, entry) {
+   list_for_each_entry (entry, list, head) {
ret = ww_mutex_lock(&entry->obj->lock, ctx);
if (ret < 0) {
entry2 = entry;

-   list_for_each_entry_continue_reverse (list, entry2)
-   ww_mutex_unlock(&entry->obj->lock);
+   list_for_each_entry_continue_reverse (entry2, list, 
head)
+   ww_mutex_unlock(&entry2->obj->lock);

if (ret != -EDEADLK) {
ww_acquire_fini(ctx);
@@ -184,8 +184,8 @@ int lock_objs(struct list_head *list, struct ww_acquire_ctx 
*ctx)
 * buf->next to the first unlocked entry,
 * restarting the for loop.
 */
-   list_del(&entry->list);
-   list_add(&entry->list, list);
+   list_del(&entry->head);
+   list_add(&entry->head, list);
}
}

@@ -199,7 +199,7 @@ void unlock_objs(struct list_head *list, struct 
ww_acquire_ctx *ctx)
 {
struct obj_entry *entry;

-   list_for_each_entry (list, entry)
+   list_for_each_entry (entry, list, head)
ww_mutex_unlock(&entry->obj->lock);

ww_acquire_fini(ctx);
@@ -244,22 +244,21 @@ struct obj {

 static DEFINE_WW_CLASS(ww_class);

-void __unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+void __unlock_objs(struct list_head *list)
 {
-   struct obj entry;
+   struct obj *entry, *temp;

-   for_each_safe (list, entry) {
+   list_for_each_entry_safe (entry, temp, list, locked_list) {
/* need to do that before unlocking, since only the current 
lock holder is
allowed to use object */
-   list_del(entry->locked_list);
+   list_del(&entry->locked_list);
ww_mutex_unlock(entry->ww_mutex)
}
 }

 void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
 {
-

[Bug 65190] New: glxgears on r600g (rv770) is garbled with llvm enabled

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 65190
  Assignee: dri-devel at lists.freedesktop.org
   Summary: glxgears on r600g (rv770) is garbled with llvm enabled
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: ace at sannes.org
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 80067
  --> https://bugs.freedesktop.org/attachment.cgi?id=80067&action=edit
output of R600-DEBUG=vs,ps glxgears

Running glxgears gives garbled output, tstellar on irc asked me to file a bug
with the output of R600_DEBUG=vs,ps glxgears

I have a rv770 card (4870) and have compiled mesa with llvm.

It does not get garbled if I run with:

R600_DEBUG=sb works.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/76b600d3/attachment.html>

[Bug 65190] glxgears on r600g (rv770) is garbled with llvm enabled

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Asbj?rn Sannes  changed:

   What|Removed |Added

  Attachment #80067|0   |1
is obsolete||

--- Comment #1 from Asbj?rn Sannes  ---
Created attachment 80068
  --> https://bugs.freedesktop.org/attachment.cgi?id=80068&action=edit
output of R600-DEBUG=vs,ps glxgears

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/a402267a/attachment.html>

[Bug 58901] "trying to bind memory to uninitialized GART" error at resume from suspend to memory

2013-05-30 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=58901





--- Comment #2 from Christian Casteyde   
2013-05-30 20:47:54 ---
No I don't think so, because it is too difficult to reproduce these times.
I wonder if suspending while playing a video helps.
It hasn't appear this week at all for instance (the warning I reported was from
last week).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #10 from mombelli.mauro at gmail.com ---
Yeh, got it, I've tryed to compile from master, then from other tag
thinking git checkout woul clear everything. My bad, I'll try to compile
again when I can. Should I use newer tag than 1.1?
I think strage that compiling mAster was on error for me.. Normally aren't
the pull self-contined?
Il giorno 30/mag/2013 09:16,  ha scritto:

>   *Comment # 9 <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c9> on bug
> 64776 <https://bugs.freedesktop.org/show_bug.cgi?id=64776> from Michel
> D?nzer  *
>
> (In reply to comment #8 
> <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c8>)> (no rure to 
> generate the ?../../../src/mapi/entry.c?, necessary for
> > ?entry.lo?.  Stop.
>
> That should only happen when switching between the master and 9.1 branches. In
> that case, the easiest solution is to make distclean and start from scratch.
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/8a00d9a8/attachment.html>

X.org's GSoC 2013 projects

2013-05-30 Thread Martin Peres

Hi everyone,

On Monday, GSoC students were informed about which projects were selected to
participate in the program. Here is a short overview of the students who 
have been
selected to work with the X.org foundation:

== DRM Render/Modeset Nodes ==
Student: David Herrmann
Mentor: Dave Airlie (airlied)
Blog: http://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/

== Add Xv support to Glamor ==
Student: Chuan He
Mentors: Arthur Huillet (ahuillet) & Alex Deucher (agd5f)
Blog: http://bigchuan.xanga.com/

== Reverse engineering NVidia's performance counters and exposing them 
via nv_perfmon ==
Student: Samuel Pitoiset (hakzsam)
Mentor: Martin Peres (mupuf)
Blog: http://hakzsam.wordpress.com/ 

== Implementing GL_EXT_direct_state_access ==
Student: Dylan Noblesmith
Mentor: Ian Romanick
Proposal: 
http://www.cs.usm.maine.edu/~noblesmith/gsoc2013proposal-ext-direct-state-access.txt

On a related note, Francisco Jerez (curro) has also been accepted to 
work on a TGSI
backend for LLVM, mentored by Tom Stellar (tstellar). This effort will 
likely bring support
for openCL to Nouveau and could also bring support to r300g, freedreno, 
etc...
Proposal: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060917.html

The project list looks pretty interesting, I hope the results will be 
just as good :)

Martin (AKA mupuf)

[Bug 65192] New: Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Priority: medium
Bug ID: 65192
Assignee: dri-devel at lists.freedesktop.org
Summary: Screensavers lock up machine (screen goes blank,
keyboard unresponsive, sound loops; sysrq/ssh
possible)
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: luziphermcleod at yahoo.ie
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa

For a while now, some screensavers sometimes lock up my machine. That means all
screens go blank, the keyboard is unresponsive (numpad-key doesn't toggle the
indicator led), the sound loops. But I still can use ssh from a remote machine
and the magic-sysrq-keys also work.

There is nothing to see in neither /var/log/messages (acquired via netconsole)
nor /var/log/Xorg.0.log.

I can trigger the bug (or regression, I think it used to work about 2 months
ago) reliably by using the Xfce4 screensaver settings application, which has a
preview of the screensaver selected. When switching between screensavers, the
lockup quickly occurs. A good candidate is the screensaver named "AntMaze", it
alsmost always locks up my machine (only worked once so far).
Other stuff works quite solid, Half-Life 2 worked multiple hours today.

Setting R600_HYPERZ=0 in /etc/environment didn't help. Also occurs on kernel
3.8.0-rc7.

I'm happy to provide more info if needed.

System Specs:
Intel Core i7-965
2x Radeon HD4870 (rv770, currently only one active without xorg.conf), 2
Monitors

Gentoo Linux
Kernel 3.10.0-rc3
Mesa 9.2.0 (git-60f9b72) git commit 60f9b722ef80c499a94b4e5ab7304dcd739ea569
Revert "i965: fix problem with constant out of bounds access (v2)"
xorg-server-1.14.1
libdrm git commit 8a88e349975a64676f143183e835e6d296f29627 modetest: Make
RGB565 pwetty too
xf86-video-ati git commit commit bd2557ea5ef84b975060e929d5ece53ec464336f DRI2:
add interpolated blanks to frame number in event handlers

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/a1fce0fa/attachment-0001.html>

[Bug 65192] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Luzipher  ---
I forgot to mention: I use the classic shader compiler at the moment and I have
egl, gles1, gles2, vdpau and wayland enabled.

Full flags on portage:
[ebuild   R   #] media-libs/mesa-::x11  USE="egl gallium gles1 gles2 llvm
nptl shared-glapi vdpau wayland -abiwrapper -bindist -classic -debug -gbm
-opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -xa
-xorg -xvmc" MULTILIB_ABI="amd64 x86" PYTHON_SINGLE_TARGET="python2_7
-python2_6" PYTHON_TARGETS="python2_7 -python2_6" VIDEO_CARDS="r600
(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -radeon
-radeonsi -vmware"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/d7964ffa/attachment.html>

[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Luzipher  changed:

   What|Removed |Added

Summary|Screensavers lock up|[r600g] Screensavers lock
   |machine (screen goes blank, |up machine (screen goes
   |keyboard unresponsive,  |blank, keyboard
   |sound loops; sysrq/ssh  |unresponsive, sound loops;
   |possible)   |sysrq/ssh possible)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/a1dd5b1c/attachment.html>

[Bug 65193] New: [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 65193
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [bisected] r600g, can't launch Gnome Shell and KDE
since mesa updated to
5de41575a127eb8a6a0fe5c71a73b372f9b89f53
  Severity: critical
Classification: Unclassified
OS: All
  Reporter: alexandre.f.demers at gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

I haven't been able to log in Gnome Shell or KDE lately since I updated mesa
from git. Using XFCE and doing some tests, I've found out glxgears returns an
assertion error when launch. glxgears fails with the following error:
sb/sb_expr.cpp:455:fold_alu_op2: Assertion `v0 && v1 && n.dst[0]' failed.
line 6: 15521 Trace/breakpoint trap   (core dumped) $1

Bisecting ended up point to culprit commit:
commit 5de41575a127eb8a6a0fe5c71a73b372f9b89f53
Author: Vadim Girlin 
Date:   Mon May 27 14:23:47 2013 +0400

r600g/sb: improve folding for SETcc

Signed-off-by: Vadim Girlin 

:04 04 96a6fd8851d84f62896ecfba6c4a7df5a7963325
ade9a1e6d7fd56ed8cf413a2138c38011f1b9827 Msrc


Using latest drm, ddx from git on a Radeon HD6950 Cayman.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/03185b18/attachment.html>

[Bug 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] r600g, can't |[bisected] r600g, can't
   |launch Gnome Shell and KDE  |launch glxgears since mesa
   |since mesa updated to   |updated to
   |5de41575a127eb8a6a0fe5c71a7 |5de41575a127eb8a6a0fe5c71a7
   |3b372f9b89f53   |3b372f9b89f53

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/9c3feed1/attachment.html>

[Bug 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Alexandre Demers  ---
It seems the identified failed assertion is not the prime root of Gnome Shell
and KDE not launching. A previous commit must be the culprit for the other
problem (I'm tracking it down right now). However, commit
5de41575a127eb8a6a0fe5c71a73b372f9b89f53 does prevent glxgears from running as
it should.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/fadb3546/attachment.html>

[Bug 65193] [bisected] r600g, can't launch glxgears since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Alexandre Demers  ---
(In reply to comment #1)
> It seems the identified failed assertion is not the prime root of Gnome
> Shell and KDE not launching. A previous commit must be the culprit for the
> other problem (I'm tracking it down right now). However, commit
> 5de41575a127eb8a6a0fe5c71a73b372f9b89f53 does prevent glxgears from running
> as it should.

Forget about what I just said, I made a mistake, wrongly resync before last
build. Retesting right away.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/ac5b55f5/attachment.html>

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

2013-05-30 Thread bugzilla-dae...@freedesktop.org

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] r600g, can't |[bisected] r600g, can't
   |launch glxgears since mesa  |launch Gnome Shell and KDE
   |updated to  |since mesa updated to
   |5de41575a127eb8a6a0fe5c71a7 |5de41575a127eb8a6a0fe5c71a7
   |3b372f9b89f53   |3b372f9b89f53

--- Comment #3 from Alexandre Demers  ---
commit 5de41575a127eb8a6a0fe5c71a73b372f9b89f53 is really the first bad commit
preventing Gnome Shell and KDE from starting correctly (Gnome ends with a Oops
and KDE just fails and relaunches X).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130530/bc480956/attachment-0001.html>

44 matches

Mail list logo