dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

[Bug 62466] New: KSP 0.19 causes GPU lockups on r600g
by bugzilla-daemon＠freedesktop.org 07 May '13

07 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=62466 Priority: medium Bug ID: 62466 Assignee: dri-devel(a)lists.freedesktop.org Summary: KSP 0.19 causes GPU lockups on r600g Severity: normal Classification: Unclassified OS: Linux (All) Reporter: knut.tidemann(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 76678 --> https://bugs.freedesktop.org/attachment.cgi?id=76678&action=edit dmesg output When trying out Kerbal Space Program for linux (version 0.19 was just released with native linux support) I get GPU lockups when constructing rockets. Everything worked well at first, but after a few minutes I got the first GPU lockup and after that it seem to lock up every 5 seconds or so, so I had to kill the game. This happens every time I run the game. MSAA and vsync were not enabled. I'm running mesa from git: Mesa 9.2.0 (git-2da8ee1) on a Radeon HD 5670 and the arch linxu kernel: Linux none 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64 GNU/Linux I've attached a full dmesg log. I'm running KDE and have two monitors set up. The lockups happened both with and without desktop effects enabled. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[PATCH 0/7] Clean up write-combining MTRR addition
by Andy Lutomirski 07 May '13

07 May '13

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 mtrr_{add,del}_wc_if_needed and drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is enabled. I've only tested the radeon driver, since I don't have test hardware easily available for the other drivers. Benefits include: - Simpler code - No more complaints about MTRR conflict warnings on PAT systems - Eventual unexporting of the MTRR API? This series eliminates about half of the mtrr_add calls in drivers/. The series is also at: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cle… Andy Lutomirski (7): x86: Add mtrr_{add,del}_wc_if_needed drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework drm_mtrr_{add,del} drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs drm: Use drm_mtrr_add_wc for the AGP aperture i915: Use drm_mtrr_{add,del}_wc radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc uvesafb: Clean up MTRR code Documentation/fb/uvesafb.txt | 16 +++----- arch/x86/include/asm/mtrr.h | 21 ++++++++++ arch/x86/kernel/cpu/mtrr/main.c | 53 +++++++++++++++++++++++++ drivers/gpu/drm/ast/ast_ttm.c | 14 ++----- drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 ++------ drivers/gpu/drm/drm_bufs.c | 11 ++---- drivers/gpu/drm/drm_pci.c | 8 ++-- drivers/gpu/drm/drm_stub.c | 10 +---- drivers/gpu/drm/drm_vm.c | 13 ++++--- drivers/gpu/drm/i915/i915_dma.c | 43 +++------------------ drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++----- drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++----- drivers/gpu/drm/radeon/radeon_object.c | 5 ++- drivers/gpu/drm/savage/savage_bci.c | 42 ++++++++------------ drivers/gpu/drm/savage/savage_drv.h | 5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 ++--- drivers/video/uvesafb.c | 70 +++++++++------------------------- include/drm/drmP.h | 23 +++++------ include/video/uvesafb.h | 1 + 19 files changed, 169 insertions(+), 218 deletions(-) -- 1.8.1.4

5 15

[PATCH] drm/exynos: fix error return code in exynos_drm_ipp_set_property()
by Wei Yongjun 07 May '13

07 May '13

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. ipp_create_cmd_work() return ERR_PTR() on error and never return NULL, so use IS_ERR() instead of IS_ERR_OR_NULL(). Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index 29d2ad3..b0d6431 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -521,20 +521,23 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, void *data, c_node->state = IPP_STATE_IDLE; c_node->start_work = ipp_create_cmd_work(); - if (IS_ERR_OR_NULL(c_node->start_work)) { + if (IS_ERR(c_node->start_work)) { DRM_ERROR("failed to create start work.\n"); + ret = PTR_ERR(c_node->start_work); goto err_clear; } c_node->stop_work = ipp_create_cmd_work(); - if (IS_ERR_OR_NULL(c_node->stop_work)) { + if (IS_ERR(c_node->stop_work)) { DRM_ERROR("failed to create stop work.\n"); + ret = PTR_ERR(c_node->stop_work); goto err_free_start; } c_node->event_work = ipp_create_event_work(); - if (IS_ERR_OR_NULL(c_node->event_work)) { + if (IS_ERR(c_node->event_work)) { DRM_ERROR("failed to create event work.\n"); + ret = PTR_ERR(c_node->event_work); goto err_free_stop; }

2 1

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
by Dave Airlie 06 May '13

06 May '13

Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer. However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have it enabled, which is less than desireable. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/udl/udl_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c index 0ce2d71..6770e1b 100644 --- a/drivers/gpu/drm/udl/udl_main.c +++ b/drivers/gpu/drm/udl/udl_main.c @@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long flags) udl->ddev = dev; dev->dev_private = udl; + dma_set_mask(dev->dev, DMA_BIT_MASK(64)); if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) { DRM_ERROR("firmware not recognized. Assume incompatible device\n"); goto err; -- 1.8.2

3 7

[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
by dl9pf＠gmx.de 06 May '13

06 May '13

From: Jan-Simon Möller <dl9pf(a)gmx.de> 20130509: v2: (re-)add inline upon request. Description: intel_gmbus_is_forced_bit is no extern as its body is right below. Likewise for intel_gmbus_is_port_valid. This fixes a compilation issue with clang. An initial version of this patch was developed by PaX Team <pageexec at freemail.hu>. This is respin of this patch. Signed-off-by: Jan-Simon Möller <dl9pf(a)gmx.de> CC: pageexec(a)freemail.hu CC: daniel.vetter(a)ffwll.ch CC: airlied(a)linux.ie CC: intel-gfx(a)lists.freedesktop.org CC: dri-devel(a)lists.freedesktop.org CC: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3ac71db..b41c49d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1806,7 +1806,7 @@ void i915_teardown_sysfs(struct drm_device *dev_priv); /* intel_i2c.c */ extern int intel_setup_gmbus(struct drm_device *dev); extern void intel_teardown_gmbus(struct drm_device *dev); -extern inline bool intel_gmbus_is_port_valid(unsigned port) +static inline bool intel_gmbus_is_port_valid(unsigned port) { return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD); } @@ -1815,7 +1815,7 @@ extern struct i2c_adapter *intel_gmbus_get_adapter( struct drm_i915_private *dev_priv, unsigned port); extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed); extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit); -extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter) +static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter) { return container_of(adapter, struct intel_gmbus, adapter)->force_bit; } -- 1.8.1.4

2 1

[Bug 62669] New: HyperZ freeze when playing PrBoom-Plus demo with lots of monsters
by bugzilla-daemon＠freedesktop.org 06 May '13

06 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=62669 Priority: medium Bug ID: 62669 Assignee: dri-devel(a)lists.freedesktop.org Summary: HyperZ freeze when playing PrBoom-Plus demo with lots of monsters Severity: normal Classification: Unclassified OS: All Reporter: lemonzest(a)gmail.com Hardware: Other Status: NEW Version: 9.1 Component: Drivers/DRI/R600 Product: Mesa I am getting a reproduceable lockup with Prboom-Plus (Its a doom game engine) when there is loads of monsters on screen, it seems to lock, starting with R600_HYPERZ=false negates the lock up. Card is a Evergreen Juniper (XFX HD6770 1GB) how to reproduce, start prboom with doom2.wad and the files and demos from here http://www.doomworld.com/idgames/index.php?id=12597 (Deus Vault) also you will require the non-free doom2.wad file from the game. and play the demo with this command from inside the unzipped dir. prboom-plus -file DV.wad -fastdemo PRBoom\ 2.2.4\ Demos/DV01-UVMAX2.lmp at some point when the player drops down a shaft to a room with many monsters it will lock does this everytime. OS is Mageia 3 Beta 4, with Mesa 9.1.1 Xorg 1.13.3 and kernel 3.8.3 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 59592] New: Reproducable GPU lockups since 3.8
by bugzilla-daemon＠freedesktop.org 06 May '13

06 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=59592 Priority: medium Bug ID: 59592 Assignee: dri-devel(a)lists.freedesktop.org Summary: Reproducable GPU lockups since 3.8 Severity: major Classification: Unclassified OS: All Reporter: nine(a)detonation.org Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 73293 --> https://bugs.freedesktop.org/attachment.cgi?id=73293&action=edit dmesg after lockups Since upgrading my kernel to 3.8.0-rc3 using openSUSE packages, I reproducably get GPU lockups when running FlightGear right after the simulation starts. Takes a couple of minutes with some screen blanking to quit the application again. Afterwards the system continues running fine. Activating KDE's desktop effects may produce the same behaviour. I'm using the following versions: Mesa-9.1_git20130117-230.1.x86_64 libdrm2-2.4.99_git20130117-1.1.x86_64 X.Org X Server 1.12.3 Release Date: 2012-07-09 [ 17.264] X Protocol Version 11, Revision 0 [ 17.264] Build Operating System: openSUSE SUSE LINUX [ 17.264] Current Operating System: Linux sphinx 3.8.0-rc3-1-desktop #1 SMP PREEMPT Thu Jan 10 20:49:22 UTC 2013 (7ce28dd) x86_64 [ 17.264] Kernel command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc3-1-desktop root=/dev/mapper/system-root resume=/dev/system/swap quiet splash=silent [ 17.264] Build Date: 08 January 2013 11:56:04AM I could do some git bisecting on the kernel or on Mesa if it helps and I'm fluent in C. Just tell me how I can help fixing this. -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 60848] New: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
by bugzilla-daemon＠freedesktop.org 06 May '13

06 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=60848 Priority: medium Bug ID: 60848 Assignee: dri-devel(a)lists.freedesktop.org Summary: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: thomas.lindroth(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 74826 --> https://bugs.freedesktop.org/attachment.cgi?id=74826&action=edit dmesg, xorg.log Commit 6532eb17baff6e61b427f29e076883f8941ae664 r600g: add htile support v16 cause a gpu lockup on juniper with Dishonored in wine. https://www.dropbox.com/s/7w140vtr48xb8vt/Dishonored.trace.bz2 this trace reproduce the error. bug #59592 is similar but I should be using the fix from that bug already. mesa, libdrm, xf86-video-ati and linus kernel are all git from yesterday. 3.0 Mesa 9.2-devel (git-ce3dfa1) Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" configure --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 --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-vdpau --disable-xvmc --enable-shared-dricore -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 63732] New: [KDE] - display switching problem with kwin_gles and radeon driver.
by bugzilla-daemon＠freedesktop.org 06 May '13

06 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=63732 Priority: medium Bug ID: 63732 Assignee: dri-devel(a)lists.freedesktop.org Summary: [KDE] - display switching problem with kwin_gles and radeon driver. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: flateric(a)atlas.cz Hardware: Other Status: NEW Version: 9.1 Component: Drivers/DRI/Radeon Product: Mesa Created attachment 78244 --> https://bugs.freedesktop.org/attachment.cgi?id=78244&action=edit Dualdisplay bug. Hello, with radeon driver and mesa in version 9.1.1 I have problem with switching display between notebook and external display in KDE 4.10.2 with kwin_gles compositor in compositing type OpenGL. Setting dual display (left/right/above) or switching between displays, causes broken screen. Please, check attached screenshot. Downgrading to mesa version 9.0.2 solve this problem. With intel GPU/Driver is everything OK. KDE version 4.10.2 GPU: ATI x1400, driver - radeon Kernel: 3.8.7 mesa version: 9.1.1 ati-dri version: 9.1.1 -- You are receiving this mail because: You are the assignee for the bug.

1 8

[PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
by dl9pf＠gmx.de 06 May '13

06 May '13

From: Jan-Simon Möller <dl9pf(a)gmx.de> Description: intel_gmbus_is_forced_bit is no extern as its body is right below. Likewise for intel_gmbus_is_port_valid. This fixes a compilation issue with clang. An initial version of this patch was developed by PaX Team <pageexec at freemail.hu>. This is respin of this patch. Signed-off-by: Jan-Simon Möller <dl9pf(a)gmx.de> CC: pageexec(a)freemail.hu CC: daniel.vetter(a)ffwll.ch CC: airlied(a)linux.ie CC: intel-gfx(a)lists.freedesktop.org CC: dri-devel(a)lists.freedesktop.org CC: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3ac71db..3c9ebc1 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1806,7 +1806,7 @@ void i915_teardown_sysfs(struct drm_device *dev_priv); /* intel_i2c.c */ extern int intel_setup_gmbus(struct drm_device *dev); extern void intel_teardown_gmbus(struct drm_device *dev); -extern inline bool intel_gmbus_is_port_valid(unsigned port) +static bool intel_gmbus_is_port_valid(unsigned port) { return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD); } @@ -1815,7 +1815,7 @@ extern struct i2c_adapter *intel_gmbus_get_adapter( struct drm_i915_private *dev_priv, unsigned port); extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed); extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit); -extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter) +static bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter) { return container_of(adapter, struct intel_gmbus, adapter)->force_bit; } -- 1.8.1.4

5 5

← Newer
1
...
63
64
65
66
67
68
69
70
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2013