dri-devel May 2014

dri-devel@lists.freedesktop.org

140 participants
970 discussions

[Bug 78242] New: Steam cannot load mesa drivers (libGL error: driver pointer missing)
by bugzilla-daemon＠freedesktop.org 12 May '14

12 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=78242 Priority: medium Bug ID: 78242 Assignee: dri-devel(a)lists.freedesktop.org Summary: Steam cannot load mesa drivers (libGL error: driver pointer missing) Severity: normal Classification: Unclassified OS: All Reporter: laszlo.kertesz(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I rebuilt mesa recently (on Debian Testing 64 bit) an i see that Steam is broken again. I get this in a terminal (accompanied by a graphical popup saying "OpenGL GLX context is not using direct rendering, which may cause performance problems.") : Running Steam on debian 64-bit STEAM_RUNTIME is enabled automatically Installing breakpad exception handler for appid(steam)/version(1398120891_client) libGL error: dlopen /usr/lib/i386-linux-gnu/dri/r600_dri.so failed (/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/r600_dri.so)) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL error: failed to load driver: r600 libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/swrast_dri.so)) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Then other Steam specific stuff. The Steam GUI launches but cannot launch anything. Now i dont know what is the issue here since i built Mesa this way since a very long time ago, with my current (gcc 4.8) compiler and had no such issues. strings /media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1 | grep GCC_4 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 GCC_4.4.0 GCC_4.5.0 Other 64 and 32 bit opengl games seems to work fine. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 78366] New: [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore)
by bugzilla-daemon＠freedesktop.org 12 May '14

12 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=78366 Priority: medium Bug ID: 78366 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore) Severity: major Classification: Unclassified OS: Linux (All) Reporter: vallesroc(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa A long time ago (months? over a year?), I used to have this issue where mesa would cause the system to leak memory over time by just idling or browsing the web (kde, firefox) and at some point (just hours) it'd be bad enough (on 8GB RAM) that over 4GB swap would be used and system would be really slow because of that. Sorting processes by ram usage (on eg: top) would show no culprits; the memory was being leaked kernelside. Not even restarting X would fix the problem: A reboot was always necessary. The issue disappeared once I started building mesa with LLVM support... until now. 10.1.2 disables LLVM for RV770, which among other things fixes games such as DOTA2, but the problem is suddenly back, making me pretty sure it's linked to not using LLVM's shader compiler (or same thing, has to do with how shaders are compiled without LLVM). -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 74551] Unable to enable ACPI
by bugzilla-daemon＠bugzilla.kernel.org 12 May '14

12 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=74551 Alex Deucher <alexdeucher(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher(a)gmail.com --- Comment #2 from Alex Deucher <alexdeucher(a)gmail.com> --- (In reply to maxis11 from comment #1) > acer aspire 5560g has problem with gpt, so I convert using gdisk gpt to mbr, > and problem seems fixed. But there is another problem, computer freezes > during boot with radeon.runpm=1. Should I create another bug report? Is that still and issue with a 3.15 kernel? I believe that should be fixed now (with patches destined for stable as well). -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 75951] New: Radeon HD, GPU CP Stall on "Octodad - Dadliest catch"
by bugzilla-daemon＠bugzilla.kernel.org 12 May '14

12 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=75951 Bug ID: 75951 Summary: Radeon HD, GPU CP Stall on "Octodad - Dadliest catch" Product: Drivers Version: 2.5 Kernel Version: 3.14.1-1-ARCH Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: kallisti5(a)unixzen.com Regression: No Created attachment 135771 --> https://bugzilla.kernel.org/attachment.cgi?id=135771&action=edit dmesg output of event. Fresh boot, directly into steam / game Running Octodad - Dadliest catch results in a severe command processor stall. Radeon HD 5970 kallisti5@eris ~ :) $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on AMD CYPRESS dmesg output attached. -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[Bug 78287] New: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
by bugzilla-daemon＠freedesktop.org 12 May '14

12 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=78287 Priority: medium Bug ID: 78287 Assignee: dri-devel(a)lists.freedesktop.org Summary: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Severity: normal Classification: Unclassified OS: Linux (All) Reporter: andabata12(a)yahoo.it Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 98460 --> https://bugs.freedesktop.org/attachment.cgi?id=98460&action=edit dmesg.txt Description of problem: On Second Life, 3D virtual world, I get recursively in dmesg the follow error message "[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!..." with subsequent Call Trace. Version-Release number of selected component (if applicable): OS: Fedora 20, Kernel: 3.15.0-0.rc3.git0.1.fc21.i686 (i686), Desktop: KDE 4.12.4, libdrm-2.4.54, Display Server: X Server 1.14.4, Display Driver: radeon 7.3.99, OpenGL: 2.1 Mesa 10.3.0-devel (git-829cb04) Gallium 0.4, Compiler: GCC 4.8.2 20131212 + LLVM 3.4, How reproducible: Logging in Second Life Steps to Reproduce: 1.Choosing a crowded Sim 2.Moving around 3.Rebuilding the 3D objects from cache Actual results: I don't have disconnections but frequent, empty frames with stuttering Expected results: Stable rebuilding Additional info: Notebook Asus F3JP with Graphics: AMD Mobility Radeon X1700 256MB -- You are receiving this mail because: You are the assignee for the bug.

1 5

[PATCH] drm/radeon: add a i2c bus mutex
by Alex Deucher 12 May '14

12 May '14

The i2c and aux buses use the same pads so add a mutex to protect access to the pads. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/radeon/atombios_dp.c | 18 ++++++++++++++---- drivers/gpu/drm/radeon/atombios_i2c.c | 17 +++++++++++++---- drivers/gpu/drm/radeon/radeon_i2c.c | 9 +++++++++ drivers/gpu/drm/radeon/radeon_mode.h | 1 + 4 files changed, 37 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index 54e4f52..3bb0933 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -95,9 +95,12 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan *chan, int index = GetIndexIntoMasterTable(COMMAND, ProcessAuxChannelTransaction); unsigned char *base; int recv_bytes; + int r = 0; memset(&args, 0, sizeof(args)); + mutex_lock(&chan->mutex); + base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1); radeon_atom_copy_swap(base, send, send_bytes, true); @@ -117,19 +120,22 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan *chan, /* timeout */ if (args.v1.ucReplyStatus == 1) { DRM_DEBUG_KMS("dp_aux_ch timeout\n"); - return -ETIMEDOUT; + r = -ETIMEDOUT; + goto done; } /* flags not zero */ if (args.v1.ucReplyStatus == 2) { DRM_DEBUG_KMS("dp_aux_ch flags not zero\n"); - return -EBUSY; + r = -EBUSY; + goto done; } /* error */ if (args.v1.ucReplyStatus == 3) { DRM_DEBUG_KMS("dp_aux_ch error\n"); - return -EIO; + r = -EIO; + goto done; } recv_bytes = args.v1.ucDataOutLen; @@ -139,7 +145,11 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan *chan, if (recv && recv_size) radeon_atom_copy_swap(recv, base + 16, recv_bytes, false); - return recv_bytes; + r = recv_bytes; +done: + mutex_unlock(&chan->mutex); + + return r; } #define BARE_ADDRESS_SIZE 3 diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c b/drivers/gpu/drm/radeon/atombios_i2c.c index b5162c3..9c570fb 100644 --- a/drivers/gpu/drm/radeon/atombios_i2c.c +++ b/drivers/gpu/drm/radeon/atombios_i2c.c @@ -43,15 +43,19 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan, int index = GetIndexIntoMasterTable(COMMAND, ProcessI2cChannelTransaction); unsigned char *base; u16 out = cpu_to_le16(0); + int r = 0; memset(&args, 0, sizeof(args)); + mutex_lock(&chan->mutex); + base = (unsigned char *)rdev->mode_info.atom_context->scratch; if (flags & HW_I2C_WRITE) { if (num > ATOM_MAX_HW_I2C_WRITE) { DRM_ERROR("hw i2c: tried to write too many bytes (%d vs 3)\n", num); - return -EINVAL; + r = -EINVAL; + goto done; } if (buf == NULL) args.ucRegIndex = 0; @@ -65,7 +69,8 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan, } else { if (num > ATOM_MAX_HW_I2C_READ) { DRM_ERROR("hw i2c: tried to read too many bytes (%d vs 255)\n", num); - return -EINVAL; + r = -EINVAL; + goto done; } args.ucRegIndex = 0; args.lpI2CDataOut = 0; @@ -82,13 +87,17 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan, /* error */ if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) { DRM_DEBUG_KMS("hw_i2c error\n"); - return -EIO; + r = -EIO; + goto done; } if (!(flags & HW_I2C_WRITE)) radeon_atom_copy_swap(buf, base, num, false); - return 0; +done: + mutex_unlock(&chan->mutex); + + return r; } int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap, diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index 7b94414..427ee4d 100644 --- a/drivers/gpu/drm/radeon/radeon_i2c.c +++ b/drivers/gpu/drm/radeon/radeon_i2c.c @@ -94,6 +94,8 @@ static int pre_xfer(struct i2c_adapter *i2c_adap) struct radeon_i2c_bus_rec *rec = &i2c->rec; uint32_t temp; + mutex_lock(&i2c->mutex); + /* RV410 appears to have a bug where the hw i2c in reset * holds the i2c port in a bad state - switch hw i2c away before * doing DDC - do this for all r200s/r300s/r400s for safety sake @@ -170,6 +172,8 @@ static void post_xfer(struct i2c_adapter *i2c_adap) temp = RREG32(rec->mask_data_reg) & ~rec->mask_data_mask; WREG32(rec->mask_data_reg, temp); temp = RREG32(rec->mask_data_reg); + + mutex_unlock(&i2c->mutex); } static int get_clock(void *i2c_priv) @@ -813,6 +817,8 @@ static int radeon_hw_i2c_xfer(struct i2c_adapter *i2c_adap, struct radeon_i2c_bus_rec *rec = &i2c->rec; int ret = 0; + mutex_lock(&i2c->mutex); + switch (rdev->family) { case CHIP_R100: case CHIP_RV100: @@ -879,6 +885,8 @@ static int radeon_hw_i2c_xfer(struct i2c_adapter *i2c_adap, break; } + mutex_unlock(&i2c->mutex); + return ret; } @@ -919,6 +927,7 @@ struct radeon_i2c_chan *radeon_i2c_create(struct drm_device *dev, i2c->adapter.dev.parent = &dev->pdev->dev; i2c->dev = dev; i2c_set_adapdata(&i2c->adapter, i2c); + mutex_init(&i2c->mutex); if (rec->mm_i2c || (rec->hw_capable && radeon_hw_i2c && diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h index 6ddf31a..b265a8b 100644 --- a/drivers/gpu/drm/radeon/radeon_mode.h +++ b/drivers/gpu/drm/radeon/radeon_mode.h @@ -191,6 +191,7 @@ struct radeon_i2c_chan { struct radeon_i2c_bus_rec rec; struct drm_dp_aux aux; bool has_aux; + struct mutex mutex; }; /* mostly for macs, but really any system without connector tables */ -- 1.8.3.1

2 1

[Bug 75651] New: resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected
by bugzilla-daemon＠bugzilla.kernel.org 12 May '14

12 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=75651 Bug ID: 75651 Summary: resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected Product: Drivers Version: 2.5 Kernel Version: 3.15 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: wshuman3(a)gmail.com Regression: No Created attachment 135311 --> https://bugzilla.kernel.org/attachment.cgi?id=135311&action=edit bisect log resume from suspend is failing for me since 3.15rc1 6d2f2944e95e504a7d33385eeeb9bb7fcca72592 is the first bad commit commit 6d2f2944e95e504a7d33385eeeb9bb7fcca72592 Author: Christian König <christian.koenig(a)amd.com> Date: Thu Feb 20 13:42:17 2014 +0100 drm/radeon: use normal BOs for the page tables v4 No need to make it more complicated than necessary, just allocate the page tables as normal BO and flush whenever the address change. v2: update comments and function name v3: squash bug fixes, page directory and tables patch v4: rebased on Mareks changes Signed-off-by: Christian König <christian.koenig(a)amd.com> :040000 040000 c7fa0e5e797db0e3384b2cd1450bf45efdb4c284 b05fc80d14d6a34db744ecee5d89035fa99ce1fe M drivers -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[PATCH 1/2] drm/ast: Fix double lock at PM resume
by Takashi Iwai 12 May '14

12 May '14

The recent commit [3ea87855: drm/helper: lock all around force mode restore] introduced drm_modeset_lock_all() in drm_helper_resume_force_mode() itself, while ast driver still takes this lock before calling it. Remove the caller side lock for avoid a fatal deadlock. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- drivers/gpu/drm/ast/ast_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 5137f15dba19..27e56dda476d 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -94,9 +94,7 @@ static int ast_drm_thaw(struct drm_device *dev) ast_post_gpu(dev); drm_mode_config_reset(dev); - drm_modeset_lock_all(dev); drm_helper_resume_force_mode(dev); - drm_modeset_unlock_all(dev); console_lock(); ast_fbdev_set_suspend(dev, 0); -- 1.9.2

3 3

[PATCH v2] nouveau: Don't check acpi_video_backlight_support() before registering backlight
by Hans de Goede 12 May '14

12 May '14

acpi_video_backlight_support() is supposed to be called by other (vendor specific) firmware backlight controls, not by native / raw backlight controls like nv_backlight. Userspace will normally prefer firmware interfaces over raw interfaces, so if acpi_video backlight support is present it will use that even if nv_backlight is registered as well. Except when video.use_native_backlight is present on the kernel cmdline (or enabled through a dmi based quirk). As the name indicates the goal here is to make only the raw interface available to userspace so that it will use that (it only does this when it sees a win8 compliant bios). This is done by: 1) Not registering any acpi_video# backlight devices; and 2) Making acpi_video_backlight_support() return true so that other firmware drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their own vender specific interfaces. Currently nouveau breaks this setup, as when acpi_video_backlight_support() returns true, it does not register itself, resulting in no backlight control at all. This is esp. going to be a problem with 3.16 which will default to video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios will get no backlight control at all. This also likely explains why the previous attempt to make video.use_native_backlight=1 the default was not a success, as without this patch having a default of video.use_native_backlight=1 will cause regressions. Note this effectively reverts commit 5bead799 Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 630f6e8..2c1e4aa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -31,7 +31,6 @@ */ #include <linux/backlight.h> -#include <linux/acpi.h> #include "nouveau_drm.h" #include "nouveau_reg.h" @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev) struct nouveau_device *device = nv_device(drm->device); struct drm_connector *connector; -#ifdef CONFIG_ACPI - if (acpi_video_backlight_support()) { - NV_INFO(drm, "ACPI backlight interface available, " - "not registering our own\n"); - return 0; - } -#endif - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS && connector->connector_type != DRM_MODE_CONNECTOR_eDP) -- 1.9.0

1 1

[Bug 70569] New: DOTA2 background and other missing elements on HD4850 GPU
by bugzilla-daemon＠freedesktop.org 12 May '14

12 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=70569 Priority: medium Bug ID: 70569 Assignee: dri-devel(a)lists.freedesktop.org Summary: DOTA2 background and other missing elements on HD4850 GPU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: vallesroc(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 87786 --> https://bugs.freedesktop.org/attachment.cgi?id=87786&action=edit Screenshot of the fountain on a newly started game On a HD4850, DOTA2 in-game background and some other objects aren't being rendered. Attached screenshot shows the problem well. DOTA2 graphics settings are at the lowest (didn't help). This is using git mesa3d on a current (~amd64) Gentoo, built both with and without LLVM shader compiler backend. Kernel is 3.12-rc5. It has, to my knowledge, never worked... I kept trying it once in a while for half a year. Since nobody else has complained yet, I suspect it's a problem that affects only the HD4xxx line of cards. -- You are receiving this mail because: You are the assignee for the bug.

1 2

← Newer
1
...
86
87
88
89
90
91
92
...
97
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2014