[Bug 50657] New: [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
https://bugs.freedesktop.org/show_bug.cgi?id=50657 Bug #: 50657 Summary: [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase Classification: Unclassified 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: thomas.lindroth at gmail.com Starting Warcraft 3 in Wine sometimes failes because of invalid command stream. It happens in about 10% of all startup attempts. After a failed startup Warcraft normally starts fine again and with improved framerate. Normal framerate after clean reboot is 110fps and directly after error it jumps to 150fps. Other applications also get improved framerate. Street fighter 4 benchmark in wine goes from 50 to 61 and glxgears from 4,000 to 10,000. The increased performance lasts for about 2 min and drops back to normal after that. It will jump again next time the error is triggered. No rendering errors can be seen. No other applications besides war3 can trigger the failed command stream. Dmesg reports: radeon :01:00.0: evergreen_surface_value_conv_check:325 depth invalid array mode 15 radeon :01:00.0: evergreen_cs_track_validate_depth:645 depth invalid (0x 0x 0x) radeon :01:00.0: evergreen_packet3_check:2015 invalid cmd stream Same message every time. No other error reported in dmesg or Xorg.log Hardware is HD 6770. Using DDX,Mesa,libdrm from latest git. Kernel 3.4.0. "ColorTiling" "true" "ColorTiling2D" "true" "SwapbuffersWait" "false" "EnablePageFlip" "true" radeon.pcie_gen2=1 War3 is invoked as "vblank_mode=0 WINEDEBUG=fps wine war3.exe -opengl" in a wine virtual desktop. The error might be build related. Building mesa with --enable-debug triggers the error more often it seems. Pipeing the output of wine to file also triggers the error. Mesa built from gentoo ebuild ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --disable-xa --disable-xorg --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11 --enable-gallium-egl --disable-d3d1x --disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-r600-llvm-compiler --disable-vdpau --disable-xvmc -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #3 from Bryan Quigley 2012-06-03 15:41:37 PDT --- Created attachment 62478 --> https://bugs.freedesktop.org/attachment.cgi?id=62478 weird screen -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #2 from Bryan Quigley 2012-06-03 14:23:51 PDT --- Created attachment 62476 --> https://bugs.freedesktop.org/attachment.cgi?id=62476 Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #1 from Bryan Quigley 2012-06-03 14:23:32 PDT --- Created attachment 62475 --> https://bugs.freedesktop.org/attachment.cgi?id=62475 syslog -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50655] New: ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 Bug #: 50655 Summary: ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x3039 last fence id 0x3030) Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: BryanQuigley at Ubuntu.com Created attachment 62474 --> https://bugs.freedesktop.org/attachment.cgi?id=62474 kern.log Tested and reproducible with Urban Terror, Warsow, and World of Padman. Used phoronix test suite, and at some point during the run of each game, it would either freeze or eventually display weird output to the screen (attached). Occasionally a VT switch would let the game "appear" again. Other times you can hear the sound of the game continue. I am using the 3.4 kernel and drivers/X, etc from Xorg Edgers PPA, which for the ati driver would be 6.14.99+git20120525.b1e9c308 and mesa is 8.1~git20120530.ff3eef1a. You should be able to reproduce this by: Installing phoronix test suite (http://www.phoronix-test-suite.com/?k=downloads) and then running: phoronix-test-suite benchmark urbanterror (or warsow or padman) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: An uninitialized return value is returned.
On Sun, Jun 3, 2012 at 6:41 PM, Il Han wrote:
> An uninitialized return value is returned.
> If the value is not necessary,
> it would be better to return the constant 0.
>
> Signed-off-by: Il Han
> ---
> ?drivers/gpu/drm/nouveau/nv04_fence.c | ? ?3 +--
> ?1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c
> b/drivers/gpu/drm/nouveau/nv04_fence.c
> index abe89db..d4091eb 100644
> --- a/drivers/gpu/drm/nouveau/nv04_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv04_fence.c
> @@ -121,7 +121,6 @@ nv04_fence_create(struct drm_device *dev)
> ?{
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
> ? ? ? ?struct nv04_fence_priv *priv;
> - ? ? ? int ret;
>
> ? ? ? ?priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> ? ? ? ?if (!priv)
> @@ -136,5 +135,5 @@ nv04_fence_create(struct drm_device *dev)
> ? ? ? ?priv->base.sync = nv04_fence_sync;
> ? ? ? ?priv->base.read = nv04_fence_read;
> ? ? ? ?dev_priv->eng[NVOBJ_ENGINE_FENCE] = >base.engine;
> - ? ? ? return ret;
> + ? ? ? return 0;
> ?}
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
Hi All,
Why not modify "int ret;" to "int ret = 0;"? Below is the benefit:
1. return the constant 0 as wish.
2. The variable ret can be used if we want.
--
Best Regards,
Bing
[PATCH] drm: An uninitialized return value is returned.
On Sun, Jun 3, 2012 at 6:41 PM, Il Han wrote:
> An uninitialized return value is returned.
> If the value is not necessary,
> it would be better to return the constant 0.
>
> Signed-off-by: Il Han
> ---
> drivers/gpu/drm/nouveau/nv04_fence.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c
> b/drivers/gpu/drm/nouveau/nv04_fence.c
> index abe89db..d4091eb 100644
> --- a/drivers/gpu/drm/nouveau/nv04_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv04_fence.c
> @@ -121,7 +121,6 @@ nv04_fence_create(struct drm_device *dev)
> {
>struct drm_nouveau_private *dev_priv = dev->dev_private;
>struct nv04_fence_priv *priv;
> - int ret;
>
>priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>if (!priv)
> @@ -136,5 +135,5 @@ nv04_fence_create(struct drm_device *dev)
>priv->base.sync = nv04_fence_sync;
>priv->base.read = nv04_fence_read;
>dev_priv->eng[NVOBJ_ENGINE_FENCE] = >base.engine;
> - return ret;
> + return 0;
> }
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi All,
Why not modify "int ret;" to "int ret = 0;"? Below is the benefit:
1. return the constant 0 as wish.
2. The variable ret can be used if we want.
Best Regards,
Bing
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120603/721bd250/attachment-0001.htm>
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #82 from thor at math.tu-berlin.de 2012-06-03 10:35:15 PDT --- Got a step further. What one can do to get a stable picture is simply to disable the scaler. For this, insert: in dvo_ns2501.c, in the function static void ns2501_mode_set the following line: ns2501_writeb(dvo, 0x08, NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN); ns2501_dpms should also et the NS2501_8_BPAS bit. Voila, I get a stable console at boot-up, and a 2D desktop. However, something still seems to be seriously broken outside of the control of the DVO driver. As soon as I start an X session, or a 3D application like tuxracer, the display vanishes. At that point, the DVO also vanishes from the i2c bus for reasons unclear to me. A vbetool post restores the i2cbus. So at least there seems to be something seriously broken with the i2c communication on this board. It also happenes that I could start the desktop, but something was wrong with EXA as characters were printed on top of each other (overlayed) instead of erased properly. glxgears seemed to work (at least once). So what is it with the i2c bus on this system? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Lots of i915/drm spew on 3.4
On Thu, May 31, 2012 at 10:22:28AM -0300, Paulo Zanoni wrote:
> 2012/5/31 Chris Wilson :
> > Before that commit we had no idea that we had run out of property slots.
> > I think the WARN is genuine, but maybe we should just bump the count set
> > it to WARN_ONCE and hope the conversion to lists arrives sooner rather
> > than latter.
> > -Chris
> >
>
> Chris is right: this is not a regression. Before that patch, no one
> checked if property creation really worked. I chose not to use
> WARN_ONCE because we need to increase the variable once for each time
> you see the message. Assuming this message appears on your log less
> than 8 times, does this patch fix your problem?
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 73e4560..bac55c2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -54,7 +54,7 @@ struct drm_mode_object {
> struct drm_object_properties *properties;
> };
>
> -#define DRM_OBJECT_MAX_PROPERTY 16
> +#define DRM_OBJECT_MAX_PROPERTY 24
> struct drm_object_properties {
> int count;
> uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
I've hit the same warn on my g33 with a tv-out sdvo. Seems to be enough to
shut it up.
Tested-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[Bug 46713] HDMI audio played back at a wrong rate
https://bugs.freedesktop.org/show_bug.cgi?id=46713 --- Comment #27 from Vincenzov 2012-06-03 09:24:50 PDT --- hi , i have compiled kernel 3.5-rc1 but radeon 5450 audio slow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon: fix vm deadlocks on cayman
Locking mutex in different orders just screams for
deadlocks, and some testing showed that it is actually
quite easy to trigger them.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_gart.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 79db56e..59d4493 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -476,12 +476,18 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
mutex_lock(>mutex);
if (last_pfn > vm->last_pfn) {
- /* grow va space 32M by 32M */
- unsigned align = ((32 << 20) >> 12) - 1;
+ /* release mutex and lock in right order */
+ mutex_unlock(>mutex);
radeon_mutex_lock(>cs_mutex);
- radeon_vm_unbind_locked(rdev, vm);
+ mutex_lock(>mutex);
+ /* and check again */
+ if (last_pfn > vm->last_pfn) {
+ /* grow va space 32M by 32M */
+ unsigned align = ((32 << 20) >> 12) - 1;
+ radeon_vm_unbind_locked(rdev, vm);
+ vm->last_pfn = (last_pfn + align) & ~align;
+ }
radeon_mutex_unlock(>cs_mutex);
- vm->last_pfn = (last_pfn + align) & ~align;
}
head = >va;
last_offset = 0;
@@ -595,8 +601,8 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
if (bo_va == NULL)
return 0;
- mutex_lock(>mutex);
radeon_mutex_lock(>cs_mutex);
+ mutex_lock(>mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
radeon_mutex_unlock(>cs_mutex);
list_del(_va->vm_list);
@@ -641,9 +647,8 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
struct radeon_bo_va *bo_va, *tmp;
int r;
- mutex_lock(>mutex);
-
radeon_mutex_lock(>cs_mutex);
+ mutex_lock(>mutex);
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(>cs_mutex);
--
1.7.9.5
Lots of i915/drm spew on 3.4
On Thu, May 31, 2012 at 11:43:21AM -0300, Paulo Zanoni wrote: > 2012/5/30 Dave Jones : > > On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote: > > ?> On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote: > > ?> ?> On Wed, May 30, 2012 at 11:31 PM, Dave Jones > > wrote: > > ?> ?> > On this hardware: > > ?> ?> > > > ?> ?> > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ > > Integrated Graphics Controller (rev 02) > > ?> ?> > > > ?> ?> > I get this every boot with Linus current tree (up to > > af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76) > > ?> ?> > > ?> ?> Just a quick question, is this a regression? > > ?> > > ?> seems so, I don't see it on 3.3 > > ?> > > ?> ?> If so, can you please > > ?> ?> attach the output of xrandr --verbose from a noisy and a quite kernel > > ?> ?> (otherwise just please attach it from this noisy kernel). > > ?> > > ?> this machine runs headless, so has no X installed right now, I'll get it > > in a while. > > > > Attached. > > > > Just a little more information: you have a lot of connector properties > because for some reason the driver thinks you have TV1, TV2 and TV3. > Each TV connector has a lot of properties... With kernel 3.3 you have > only TV1 and TV2. Maybe instead of increasing the maximum property > count we should try to investigate why there's a new TV connector in > the new kernel (and maybe this is also not a bug/regression...). I've merged a patch from Chris to detect additional sdvo TV outputs: commit a0b1c7a5197293d6206b245b45edc3f508aadab6 Author: Chris Wilson Date: Fri Sep 30 22:56:41 2011 +0100 drm/i915/sdvo: Include YRPB as an additional TV output type So that explains that hopefully. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm: An uninitialized return value is returned.
On Sun, Jun 3, 2012 at 2:26 PM, bing deng wrote: > Hi All, > > ? ?Why not modify "int ret;" to "int ret = 0;"? Below is the benefit: > ? ?1. return the constant 0 as wish. > ? ?2. The variable ret can be used if we want. Why? ret is in vain and wastes memory... -- Thanks, //richard
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #41 from darkbasic 2012-06-03 08:25:36 PDT --- Really? Thanks for that, that's an awesome news. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50616] glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #3 from Lauri Kasanen 2012-06-03 08:22:27 PDT --- No, it does not. It improved the average a tiny bit, but the long ones were still there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #40 from Alex Deucher 2012-06-03 08:09:46 PDT --- The kernel patches are already upstream. All you need are the mesa patches. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50616] glClear occasionally taking >60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #2 from Alex Deucher 2012-06-03 08:08:04 PDT --- Does setting: Option "SwapbuffersWait" "false" in the device section of your xorg.conf help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon: fix vm deadlocks on cayman
On Sun, Jun 3, 2012 at 10:09 AM, Christian K?nig
wrote:
> Locking mutex in different orders just screams for
> deadlocks, and some testing showed that it is actually
> quite easy to trigger them.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> Cc: stable at vger.kernel.org
> ---
> ?drivers/gpu/drm/radeon/radeon_gart.c | ? 19 ---
> ?1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 79db56e..59d4493 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -476,12 +476,18 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
>
> ? ? ? ?mutex_lock(>mutex);
> ? ? ? ?if (last_pfn > vm->last_pfn) {
> - ? ? ? ? ? ? ? /* grow va space 32M by 32M */
> - ? ? ? ? ? ? ? unsigned align = ((32 << 20) >> 12) - 1;
> + ? ? ? ? ? ? ? /* release mutex and lock in right order */
> + ? ? ? ? ? ? ? mutex_unlock(>mutex);
> ? ? ? ? ? ? ? ?radeon_mutex_lock(>cs_mutex);
> - ? ? ? ? ? ? ? radeon_vm_unbind_locked(rdev, vm);
> + ? ? ? ? ? ? ? mutex_lock(>mutex);
> + ? ? ? ? ? ? ? /* and check again */
> + ? ? ? ? ? ? ? if (last_pfn > vm->last_pfn) {
> + ? ? ? ? ? ? ? ? ? ? ? /* grow va space 32M by 32M */
> + ? ? ? ? ? ? ? ? ? ? ? unsigned align = ((32 << 20) >> 12) - 1;
> + ? ? ? ? ? ? ? ? ? ? ? radeon_vm_unbind_locked(rdev, vm);
> + ? ? ? ? ? ? ? ? ? ? ? vm->last_pfn = (last_pfn + align) & ~align;
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?radeon_mutex_unlock(>cs_mutex);
> - ? ? ? ? ? ? ? vm->last_pfn = (last_pfn + align) & ~align;
> ? ? ? ?}
> ? ? ? ?head = >va;
> ? ? ? ?last_offset = 0;
> @@ -595,8 +601,8 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
> ? ? ? ?if (bo_va == NULL)
> ? ? ? ? ? ? ? ?return 0;
>
> - ? ? ? mutex_lock(>mutex);
> ? ? ? ?radeon_mutex_lock(>cs_mutex);
> + ? ? ? mutex_lock(>mutex);
> ? ? ? ?radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
> ? ? ? ?radeon_mutex_unlock(>cs_mutex);
> ? ? ? ?list_del(_va->vm_list);
> @@ -641,9 +647,8 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
> radeon_vm *vm)
> ? ? ? ?struct radeon_bo_va *bo_va, *tmp;
> ? ? ? ?int r;
>
> - ? ? ? mutex_lock(>mutex);
> -
> ? ? ? ?radeon_mutex_lock(>cs_mutex);
> + ? ? ? mutex_lock(>mutex);
> ? ? ? ?radeon_vm_unbind_locked(rdev, vm);
> ? ? ? ?radeon_mutex_unlock(>cs_mutex);
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Make PM info available to all, not just debug users
On 02.06.2012 18:08, Lauri Kasanen wrote:
> Hi all
>
> This moves the pm_info file from debugfs to next to the other two power files.
>
> Requested by several users at Phoronix.
>
> PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
>
> Signed-off-by: Lauri Kasanen
Hui? What should this be good for?
Sysfs files are for setting driver parameters, like the power management
method or profile currently in use. One major advantage of sysfs is the
strict rules for a permanent and machine usable interface, for example
it is mandatory to only specify one parameter per sysfs file.
Debugfs on the other hand should be used for human readable
informations, e.g. the printing the current clocks in a human readable
form. Also you don't need a debug build or turn on any other debugging
facility to get those information, just take a look under
"sys/kernel/debug/dri/*".
So the code is actually quite valid as it is.
Regards,
Christian.
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 86
> ++-
> 1 files changed, 44 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 0882554..7aab18f 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -45,7 +45,6 @@ static const char *radeon_pm_state_type_name[5] = {
> };
>
> static void radeon_dynpm_idle_work_handler(struct work_struct *work);
> -static int radeon_debugfs_pm_init(struct radeon_device *rdev);
> static bool radeon_pm_in_vbl(struct radeon_device *rdev);
> static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
> finish);
> static void radeon_pm_update_profile(struct radeon_device *rdev);
> @@ -437,8 +436,49 @@ fail:
> return count;
> }
>
> +static ssize_t radeon_get_pm_info(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct radeon_device *rdev = ddev->dev_private;
> +
> + ssize_t curpos, len = PAGE_SIZE;
> + char *tmp;
> +
> + curpos = snprintf(buf, len,
> + "default engine clock: %u0 kHz\n"
> + "current engine clock: %u0 kHz\n"
> + "default memory clock: %u0 kHz\n",
> + rdev->pm.default_sclk,
> + radeon_get_engine_clock(rdev),
> + rdev->pm.default_mclk);
> + len -= curpos;
> +
> + if (rdev->asic->get_memory_clock) {
> + tmp = buf + curpos;
> + curpos += snprintf(tmp, len, "current memory clock: %u0 kHz\n",
> radeon_get_memory_clock(rdev));
> + len = PAGE_SIZE - curpos;
> + }
> +
> + if (rdev->pm.current_vddc) {
> + tmp = buf + curpos;
> + curpos += snprintf(tmp, len, "voltage: %u mV\n",
> rdev->pm.current_vddc);
> + len = PAGE_SIZE - curpos;
> + }
> +
> + if (rdev->asic->get_pcie_lanes) {
> + tmp = buf + curpos;
> + curpos += snprintf(tmp, len, "PCIE lanes: %d\n",
> radeon_get_pcie_lanes(rdev));
> + len = PAGE_SIZE - curpos;
> + }
> +
> + return curpos;
> +}
> +
> static DEVICE_ATTR(power_profile, S_IRUGO | S_IWUSR, radeon_get_pm_profile,
> radeon_set_pm_profile);
> static DEVICE_ATTR(power_method, S_IRUGO | S_IWUSR, radeon_get_pm_method,
> radeon_set_pm_method);
> +static DEVICE_ATTR(power_info, S_IRUGO, radeon_get_pm_info, NULL);
>
> static ssize_t radeon_hwmon_show_temp(struct device *dev,
> struct device_attribute *attr,
> @@ -639,14 +679,14 @@ int radeon_pm_init(struct radeon_device *rdev)
> ret = device_create_file(rdev->dev,_attr_power_method);
> if (ret)
> DRM_ERROR("failed to create device file for power
> method\n");
> + ret = device_create_file(rdev->dev,_attr_power_info);
> + if (ret)
> + DRM_ERROR("failed to create device file for power
> info\n");
>
> #ifdef CONFIG_ACPI
> rdev->acpi_nb.notifier_call = radeon_acpi_event;
> register_acpi_notifier(>acpi_nb);
> #endif
> - if (radeon_debugfs_pm_init(rdev)) {
> - DRM_ERROR("Failed to register debugfs file for PM!\n");
> - }
>
> DRM_INFO("radeon: power management initialized\n");
> }
> @@ -843,41 +883,3 @@ static void radeon_dynpm_idle_work_handler(struct
> work_struct *work)
> mutex_unlock(>pm.mutex);
> ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
> }
> -
> -/*
> - * Debugfs info
> - */
> -#if defined(CONFIG_DEBUG_FS)
> -
> -static int radeon_debugfs_pm_info(struct seq_file *m, void *data)
> -{
> - struct drm_info_node *node = (struct drm_info_node *) m->private;
> - struct
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #39 from darkbasic 2012-06-03 04:57:25 PDT --- I fear nobody is working on hi-z anymore... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #38 from ryszardzonk at yahoo.com 2012-06-02 23:45:20 PDT --- I just checked back with the bug to see how the development is going and seems either I am doing something wrong or that patches updated by Jerome Glisse would need to be updated again for kernel 3.4 or 3.5-rc1 and mesa git master as they do not apply for me :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #38 from ryszardz...@yahoo.com 2012-06-02 23:45:20 PDT --- I just checked back with the bug to see how the development is going and seems either I am doing something wrong or that patches updated by Jerome Glisse would need to be updated again for kernel 3.4 or 3.5-rc1 and mesa git master as they do not apply for me :( -- 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: [PATCH] radeon: Make PM info available to all, not just debug users
On 02.06.2012 18:08, Lauri Kasanen wrote:
Hi all
This moves the pm_info file from debugfs to next to the other two power files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
Signed-off-by: Lauri Kasanenc...@gmx.com
Hui? What should this be good for?
Sysfs files are for setting driver parameters, like the power management
method or profile currently in use. One major advantage of sysfs is the
strict rules for a permanent and machine usable interface, for example
it is mandatory to only specify one parameter per sysfs file.
Debugfs on the other hand should be used for human readable
informations, e.g. the printing the current clocks in a human readable
form. Also you don't need a debug build or turn on any other debugging
facility to get those information, just take a look under
sys/kernel/debug/dri/*.
So the code is actually quite valid as it is.
Regards,
Christian.
---
drivers/gpu/drm/radeon/radeon_pm.c | 86 ++-
1 files changed, 44 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0882554..7aab18f 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -45,7 +45,6 @@ static const char *radeon_pm_state_type_name[5] = {
};
static void radeon_dynpm_idle_work_handler(struct work_struct *work);
-static int radeon_debugfs_pm_init(struct radeon_device *rdev);
static bool radeon_pm_in_vbl(struct radeon_device *rdev);
static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
finish);
static void radeon_pm_update_profile(struct radeon_device *rdev);
@@ -437,8 +436,49 @@ fail:
return count;
}
+static ssize_t radeon_get_pm_info(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct radeon_device *rdev = ddev-dev_private;
+
+ ssize_t curpos, len = PAGE_SIZE;
+ char *tmp;
+
+ curpos = snprintf(buf, len,
+ default engine clock: %u0 kHz\n
+ current engine clock: %u0 kHz\n
+ default memory clock: %u0 kHz\n,
+ rdev-pm.default_sclk,
+ radeon_get_engine_clock(rdev),
+ rdev-pm.default_mclk);
+ len -= curpos;
+
+ if (rdev-asic-get_memory_clock) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev-pm.current_vddc) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, voltage: %u mV\n,
rdev-pm.current_vddc);
+ len = PAGE_SIZE - curpos;
+ }
+
+ if (rdev-asic-get_pcie_lanes) {
+ tmp = buf + curpos;
+ curpos += snprintf(tmp, len, PCIE lanes: %d\n,
radeon_get_pcie_lanes(rdev));
+ len = PAGE_SIZE - curpos;
+ }
+
+ return curpos;
+}
+
static DEVICE_ATTR(power_profile, S_IRUGO | S_IWUSR, radeon_get_pm_profile,
radeon_set_pm_profile);
static DEVICE_ATTR(power_method, S_IRUGO | S_IWUSR, radeon_get_pm_method,
radeon_set_pm_method);
+static DEVICE_ATTR(power_info, S_IRUGO, radeon_get_pm_info, NULL);
static ssize_t radeon_hwmon_show_temp(struct device *dev,
struct device_attribute *attr,
@@ -639,14 +679,14 @@ int radeon_pm_init(struct radeon_device *rdev)
ret = device_create_file(rdev-dev,dev_attr_power_method);
if (ret)
DRM_ERROR(failed to create device file for power
method\n);
+ ret = device_create_file(rdev-dev,dev_attr_power_info);
+ if (ret)
+ DRM_ERROR(failed to create device file for power
info\n);
#ifdef CONFIG_ACPI
rdev-acpi_nb.notifier_call = radeon_acpi_event;
register_acpi_notifier(rdev-acpi_nb);
#endif
- if (radeon_debugfs_pm_init(rdev)) {
- DRM_ERROR(Failed to register debugfs file for PM!\n);
- }
DRM_INFO(radeon: power management initialized\n);
}
@@ -843,41 +883,3 @@ static void radeon_dynpm_idle_work_handler(struct
work_struct *work)
mutex_unlock(rdev-pm.mutex);
ttm_bo_unlock_delayed_workqueue(rdev-mman.bdev, resched);
}
-
-/*
- * Debugfs info
- */
-#if defined(CONFIG_DEBUG_FS)
-
-static int radeon_debugfs_pm_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m-private;
- struct drm_device *dev = node-minor-dev;
- struct radeon_device *rdev = dev-dev_private;
-
- seq_printf(m, default engine clock:
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 --- Comment #5 from Christian König deathsim...@vodafone.de 2012-06-03 03:58:12 PDT --- Those integrated chipsets like IGPs and APUs current don't have a full power management implementation. So they are running with whatever is the (very slow) default speed the BIOS is programming at boot. Alex is working on advanced power management, so I'm not so deep into it, but AFAIK this should be improving in the near future. Also it is not limited to MPEG2 decoding with the 3D engine, 3D in general is far to slow on those chipsets. Christian. -- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #39 from darkbasic darkba...@linuxsystems.it 2012-06-03 04:57:25 PDT --- I fear nobody is working on hi-z anymore... -- 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: Lots of i915/drm spew on 3.4
On Thu, May 31, 2012 at 11:43:21AM -0300, Paulo Zanoni wrote: 2012/5/30 Dave Jones da...@redhat.com: On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote: On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote: On Wed, May 30, 2012 at 11:31 PM, Dave Jones da...@redhat.com wrote: On this hardware: 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) I get this every boot with Linus current tree (up to af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76) Just a quick question, is this a regression? seems so, I don't see it on 3.3 If so, can you please attach the output of xrandr --verbose from a noisy and a quite kernel (otherwise just please attach it from this noisy kernel). this machine runs headless, so has no X installed right now, I'll get it in a while. Attached. Just a little more information: you have a lot of connector properties because for some reason the driver thinks you have TV1, TV2 and TV3. Each TV connector has a lot of properties... With kernel 3.3 you have only TV1 and TV2. Maybe instead of increasing the maximum property count we should try to investigate why there's a new TV connector in the new kernel (and maybe this is also not a bug/regression...). I've merged a patch from Chris to detect additional sdvo TV outputs: commit a0b1c7a5197293d6206b245b45edc3f508aadab6 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Sep 30 22:56:41 2011 +0100 drm/i915/sdvo: Include YRPB as an additional TV output type So that explains that hopefully. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix vm deadlocks on cayman
Locking mutex in different orders just screams for
deadlocks, and some testing showed that it is actually
quite easy to trigger them.
Signed-off-by: Christian König deathsim...@vodafone.de
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_gart.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 79db56e..59d4493 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -476,12 +476,18 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
mutex_lock(vm-mutex);
if (last_pfn vm-last_pfn) {
- /* grow va space 32M by 32M */
- unsigned align = ((32 20) 12) - 1;
+ /* release mutex and lock in right order */
+ mutex_unlock(vm-mutex);
radeon_mutex_lock(rdev-cs_mutex);
- radeon_vm_unbind_locked(rdev, vm);
+ mutex_lock(vm-mutex);
+ /* and check again */
+ if (last_pfn vm-last_pfn) {
+ /* grow va space 32M by 32M */
+ unsigned align = ((32 20) 12) - 1;
+ radeon_vm_unbind_locked(rdev, vm);
+ vm-last_pfn = (last_pfn + align) ~align;
+ }
radeon_mutex_unlock(rdev-cs_mutex);
- vm-last_pfn = (last_pfn + align) ~align;
}
head = vm-va;
last_offset = 0;
@@ -595,8 +601,8 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
if (bo_va == NULL)
return 0;
- mutex_lock(vm-mutex);
radeon_mutex_lock(rdev-cs_mutex);
+ mutex_lock(vm-mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
radeon_mutex_unlock(rdev-cs_mutex);
list_del(bo_va-vm_list);
@@ -641,9 +647,8 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
struct radeon_bo_va *bo_va, *tmp;
int r;
- mutex_lock(vm-mutex);
-
radeon_mutex_lock(rdev-cs_mutex);
+ mutex_lock(vm-mutex);
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(rdev-cs_mutex);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50616] glClear occasionally taking 60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #2 from Alex Deucher ag...@yahoo.com 2012-06-03 08:08:04 PDT --- Does setting: Option SwapbuffersWait false in the device section of your xorg.conf help? -- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #40 from Alex Deucher ag...@yahoo.com 2012-06-03 08:09:46 PDT --- The kernel patches are already upstream. All you need are the mesa patches. -- 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: Lots of i915/drm spew on 3.4
On Thu, May 31, 2012 at 10:22:28AM -0300, Paulo Zanoni wrote:
2012/5/31 Chris Wilson ch...@chris-wilson.co.uk:
Before that commit we had no idea that we had run out of property slots.
I think the WARN is genuine, but maybe we should just bump the count set
it to WARN_ONCE and hope the conversion to lists arrives sooner rather
than latter.
-Chris
Chris is right: this is not a regression. Before that patch, no one
checked if property creation really worked. I chose not to use
WARN_ONCE because we need to increase the variable once for each time
you see the message. Assuming this message appears on your log less
than 8 times, does this patch fix your problem?
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73e4560..bac55c2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -54,7 +54,7 @@ struct drm_mode_object {
struct drm_object_properties *properties;
};
-#define DRM_OBJECT_MAX_PROPERTY 16
+#define DRM_OBJECT_MAX_PROPERTY 24
struct drm_object_properties {
int count;
uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
I've hit the same warn on my g33 with a tv-out sdvo. Seems to be enough to
shut it up.
Tested-by: Daniel Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50616] glClear occasionally taking 60ms
https://bugs.freedesktop.org/show_bug.cgi?id=50616 --- Comment #3 from Lauri Kasanen cur...@operamail.com 2012-06-03 08:22:27 PDT --- No, it does not. It improved the average a tiny bit, but the long ones were still there. -- 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 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #41 from darkbasic darkba...@linuxsystems.it 2012-06-03 08:25:36 PDT --- Really? Thanks for that, that's an awesome news. -- 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 46713] HDMI audio played back at a wrong rate
https://bugs.freedesktop.org/show_bug.cgi?id=46713 --- Comment #27 from Vincenzov vincenzo...@hotmail.com 2012-06-03 09:24:50 PDT --- hi , i have compiled kernel 3.5-rc1 but radeon 5450 audio slow. -- 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: [PATCH] drm/radeon: fix vm deadlocks on cayman
On Sun, Jun 3, 2012 at 10:09 AM, Christian König
deathsim...@vodafone.de wrote:
Locking mutex in different orders just screams for
deadlocks, and some testing showed that it is actually
quite easy to trigger them.
Signed-off-by: Christian König deathsim...@vodafone.de
Reviewed-by: Jerome Glisse jgli...@redhat.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_gart.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 79db56e..59d4493 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -476,12 +476,18 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
mutex_lock(vm-mutex);
if (last_pfn vm-last_pfn) {
- /* grow va space 32M by 32M */
- unsigned align = ((32 20) 12) - 1;
+ /* release mutex and lock in right order */
+ mutex_unlock(vm-mutex);
radeon_mutex_lock(rdev-cs_mutex);
- radeon_vm_unbind_locked(rdev, vm);
+ mutex_lock(vm-mutex);
+ /* and check again */
+ if (last_pfn vm-last_pfn) {
+ /* grow va space 32M by 32M */
+ unsigned align = ((32 20) 12) - 1;
+ radeon_vm_unbind_locked(rdev, vm);
+ vm-last_pfn = (last_pfn + align) ~align;
+ }
radeon_mutex_unlock(rdev-cs_mutex);
- vm-last_pfn = (last_pfn + align) ~align;
}
head = vm-va;
last_offset = 0;
@@ -595,8 +601,8 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
if (bo_va == NULL)
return 0;
- mutex_lock(vm-mutex);
radeon_mutex_lock(rdev-cs_mutex);
+ mutex_lock(vm-mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
radeon_mutex_unlock(rdev-cs_mutex);
list_del(bo_va-vm_list);
@@ -641,9 +647,8 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
struct radeon_bo_va *bo_va, *tmp;
int r;
- mutex_lock(vm-mutex);
-
radeon_mutex_lock(rdev-cs_mutex);
+ mutex_lock(vm-mutex);
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(rdev-cs_mutex);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #82 from t...@math.tu-berlin.de 2012-06-03 10:35:15 PDT --- Got a step further. What one can do to get a stable picture is simply to disable the scaler. For this, insert: in dvo_ns2501.c, in the function static void ns2501_mode_set the following line: ns2501_writeb(dvo, 0x08, NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN); ns2501_dpms should also et the NS2501_8_BPAS bit. Voila, I get a stable console at boot-up, and a 2D desktop. However, something still seems to be seriously broken outside of the control of the DVO driver. As soon as I start an X session, or a 3D application like tuxracer, the display vanishes. At that point, the DVO also vanishes from the i2c bus for reasons unclear to me. A vbetool post restores the i2cbus. So at least there seems to be something seriously broken with the i2c communication on this board. It also happenes that I could start the desktop, but something was wrong with EXA as characters were printed on top of each other (overlayed) instead of erased properly. glxgears seemed to work (at least once). So what is it with the i2c bus on this system? -- 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 50655] New: ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 Bug #: 50655 Summary: ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x3039 last fence id 0x3030) Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: bryanquig...@ubuntu.com Created attachment 62474 -- https://bugs.freedesktop.org/attachment.cgi?id=62474 kern.log Tested and reproducible with Urban Terror, Warsow, and World of Padman. Used phoronix test suite, and at some point during the run of each game, it would either freeze or eventually display weird output to the screen (attached). Occasionally a VT switch would let the game appear again. Other times you can hear the sound of the game continue. I am using the 3.4 kernel and drivers/X, etc from Xorg Edgers PPA, which for the ati driver would be 6.14.99+git20120525.b1e9c308 and mesa is 8.1~git20120530.ff3eef1a. You should be able to reproduce this by: Installing phoronix test suite (http://www.phoronix-test-suite.com/?k=downloads) and then running: phoronix-test-suite benchmark urbanterror (or warsow or padman) -- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #1 from Bryan Quigley bryanquig...@ubuntu.com 2012-06-03 14:23:32 PDT --- Created attachment 62475 -- https://bugs.freedesktop.org/attachment.cgi?id=62475 syslog -- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #2 from Bryan Quigley bryanquig...@ubuntu.com 2012-06-03 14:23:51 PDT --- Created attachment 62476 -- https://bugs.freedesktop.org/attachment.cgi?id=62476 Xorg log -- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #3 from Bryan Quigley bryanquig...@ubuntu.com 2012-06-03 15:41:37 PDT --- Created attachment 62478 -- https://bugs.freedesktop.org/attachment.cgi?id=62478 weird screen -- 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 50657] New: [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
https://bugs.freedesktop.org/show_bug.cgi?id=50657 Bug #: 50657 Summary: [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase Classification: Unclassified 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: thomas.lindr...@gmail.com Starting Warcraft 3 in Wine sometimes failes because of invalid command stream. It happens in about 10% of all startup attempts. After a failed startup Warcraft normally starts fine again and with improved framerate. Normal framerate after clean reboot is 110fps and directly after error it jumps to 150fps. Other applications also get improved framerate. Street fighter 4 benchmark in wine goes from 50 to 61 and glxgears from 4,000 to 10,000. The increased performance lasts for about 2 min and drops back to normal after that. It will jump again next time the error is triggered. No rendering errors can be seen. No other applications besides war3 can trigger the failed command stream. Dmesg reports: radeon :01:00.0: evergreen_surface_value_conv_check:325 depth invalid array mode 15 radeon :01:00.0: evergreen_cs_track_validate_depth:645 depth invalid (0x 0x 0x) radeon :01:00.0: evergreen_packet3_check:2015 invalid cmd stream Same message every time. No other error reported in dmesg or Xorg.log Hardware is HD 6770. Using DDX,Mesa,libdrm from latest git. Kernel 3.4.0. ColorTiling true ColorTiling2D true SwapbuffersWait false EnablePageFlip true radeon.pcie_gen2=1 War3 is invoked as vblank_mode=0 WINEDEBUG=fps wine war3.exe -opengl in a wine virtual desktop. The error might be build related. Building mesa with --enable-debug triggers the error more often it seems. Pipeing the output of wine to file also triggers the error. Mesa built from gentoo ebuild ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --disable-xa --disable-xorg --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11 --enable-gallium-egl --disable-d3d1x --disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-r600-llvm-compiler --disable-vdpau --disable-xvmc -- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #57 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-06-03 18:26:12 PDT --- Now running kernel 3.5-rc1 with latest mesa, drm, ddx and still locking the GPU. As always, easy to reproduce by running piglit r600 tests. -- 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
