dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
by bugzilla-daemon＠bugzilla.kernel.org 17 Jan '16

17 Jan '16

https://bugzilla.kernel.org/show_bug.cgi?id=88861 Jani Nikula <jani.nikula(a)intel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|intel-gfx-bugs(a)lists.freede |dri-devel(a)lists.freedesktop |sktop.org |.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

Fixing system lockup after GPU reset on SI (Radeon HD 7970 GHz edition)
by Matthew Dawson 17 Jan '16

17 Jan '16

Hi all, I'm trying to work through this bug: https://bugs.freedesktop.org/ show_bug.cgi?id=93649 . The main symptom that something has gone wrong is the system locks up, with some process trying to reset the gpu while the gpu is trying to be reset which deadlocks. The system still works over ssh, just the graphics get stuck. I'm trying to fix the kernel side of this first, so my gpu can reliably reset when the game triggers the gpu lockup, after which I'll try tracking down the mesa issue which causes the lockup in the first place. I've started some preliminary investigating, but I'm running out of ideas as public documentation on some of the AMD hardware is currently not available. As far as I can tell, when the radeon module tries to reset the GPU it will always fail to bring up the VCE (which I haven't looked at yet, as it doesn't seem to be involved with this issue.) and the UVD. The VCE failure is caught early, and so the kernel module just ignores the whole thing. However, the UVD claims to initialize properly. But when the kernel module tries to run a test IB on the UVD ring, it stalls forever. Note: before any issues, the UVD works on my GPU, tested with a random media file and vlc. I poked IRC some time ago, where Dave Airlie suggested that UVD is really unhappy with being reset, and to try disabling that as a test. Nothing I tried yielded any improvement. I also noticed that the SMC (I assume that is some sort of power manager? I didn't find anything on it besides the source code) fails to initialize after a reset, with the error: [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed I'm wondering if this might be causing the issue instead, as the source code fiddles with the UVD after this error. Not knowing more, I can't say for sure. Details on testing done: For the UVD, I tried forcing it to be completely reset by setting the appropriate bit in SRBM_SOFT_RESET, but that still cause the failure to happen in the same place. Based on the advice from IRC, I tried disabling large parts of the UVD startup and shutdown code, to avoid disabling anything. Some of the initialization process also disabled parts of the UVD, which is which it was disabled. There was no change. Note the initial start was never changed, and vlc was always able to play a video using it. Suspecting the SMC, I've got the return code from the message sent in si_set_sw_state. It always returns 0x0, which doesn't have a name in the source code. I guess this means a timeout, from looking at the code. I have no idea where to look further I couldn't find any documentation. If there is any I missed, I'd be happy to take a look and see what is going on. I also captured traces of every command sent to the SMC, if that would help. I haven't checked them much, other then to note they are different then on boot. Also, is there a bit in either GRBM_SOFT_RESET or SRBM_SOFT_RESET to reset the SMC? I'm just curious if that might help. I've been using vlc playing a movie while forcing a gpu reset through debugfs to speed up testing, as it quickly and reliably causes this issue. I can also reproduce this with TF2 reliably, it just takes 30-60 minutes to test. For solutions I was hopeful on, I'd use TF2 to confirm that vlc using the UVD wasn't causing a failure on reset different from the TF2 one. Any help in debugging this issue would be greatly appreciated. Any documentation I can review to better understand the GPU would be helpful. I already checked the documentation linked to from the fdo wiki, but it didn't mention this part. One last thing, I can partial work around the hang by allowing the ib test of the UVD to time out. I've used a long time out (20 seconds) for testing. Would a patch limiting this be accepted? It might allow users who run into this to recover (sometimes TF2 will recover thanks to that workaround, and continuing playing. Sometimes the system still lockups due to other issues, but those don't seem to be hardware errors so I rather work on that later). Right now I add a timeout to every call to radeon_fence_wait, but if that isn't a good idea I could add another similar function (radeon_fence_wait_timeout?) that takes a timeout, and update the ring tests appropriately. Thanks for reading my wall of text, -- Matthew

1 1

[PATCH RFC] drm/i2c: tda998x: Only set atomic funcs if bound to atomic drm driver
by Jyri Sarha 16 Jan '16

16 Jan '16

Only set atomic connector callbacks if the tda998x driver is bound to a drm driver that supports atomic modesetting. At least drm_crtc_helper_set_config() calls connectors dpms callback without knowing that it may assume atomic modeset support. Calling drm_atomic_helper_connector_dpms() causes a crash with a driver that does not have atomic state initialized. Fixes commit 9736e988d328 ("drm/i2c: tda998x: Add support for atomic modesetting"). Signed-off-by: Jyri Sarha <jsarha(a)ti.com> --- I am not sure if this is the best way to fix the issue, but after 9736e988d328 Beaglebone-Black HDMI is totally broken and this fixes the issue. I am currently working on atomic modesetting for tilcdc, but there is no way it makes it to 4.5 release. Best regards, Jyri drivers/gpu/drm/i2c/tda998x_drv.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 012d36d..67d1408 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1382,7 +1382,7 @@ static void tda998x_connector_destroy(struct drm_connector *connector) drm_connector_cleanup(connector); } -static const struct drm_connector_funcs tda998x_connector_funcs = { +static const struct drm_connector_funcs tda998x_connector_atomic_funcs = { .dpms = drm_atomic_helper_connector_dpms, .reset = drm_atomic_helper_connector_reset, .fill_modes = drm_helper_probe_single_connector_modes, @@ -1392,15 +1392,28 @@ static const struct drm_connector_funcs tda998x_connector_funcs = { .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, }; +static const struct drm_connector_funcs tda998x_connector_funcs = { + .dpms = drm_helper_connector_dpms, + .fill_modes = drm_helper_probe_single_connector_modes, + .detect = tda998x_connector_detect, + .destroy = tda998x_connector_destroy, +}; + static int tda998x_bind(struct device *dev, struct device *master, void *data) { struct tda998x_encoder_params *params = dev->platform_data; struct i2c_client *client = to_i2c_client(dev); struct drm_device *drm = data; struct tda998x_priv *priv; + const struct drm_connector_funcs *connector_funcs; u32 crtcs = 0; int ret; + if (drm_core_check_feature(drm, DRIVER_ATOMIC)) + connector_funcs = &tda998x_connector_atomic_funcs; + else + connector_funcs = &tda998x_connector_funcs; + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; @@ -1437,7 +1450,7 @@ static int tda998x_bind(struct device *dev, struct device *master, void *data) drm_connector_helper_add(&priv->connector, &tda998x_connector_helper_funcs); ret = drm_connector_init(drm, &priv->connector, - &tda998x_connector_funcs, + connector_funcs, DRM_MODE_CONNECTOR_HDMIA); if (ret) goto err_connector; -- 1.9.1

2 2

[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm
by bugzilla-daemon＠freedesktop.org 16 Jan '16

16 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=93614 Bug ID: 93614 Summary: Tonga general protection fault in libdrm_amdgpu at di.fm Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bpaterni(a)gmail.com Created attachment 120836 --> https://bugs.freedesktop.org/attachment.cgi?id=120836&action=edit Debian's xserver-xorg-video-amdgpu bugscript output Dear Maintainer, di.fm's f2p streaming service is now only available through their website -- the downloadable playlist steams that used to be available now redirect people to the website -- and as a result I pulled up di.fm to attempt to play one of their steam. But instead of music, I see that the flashplugin has apparently crashed and a general protection fault pointing to libdrm_amdgpu has occurred and is reported in dmesg: [21182.057540] traps: plugin-containe[32761] general protection ip:7f33d2ce0148 sp:7fff24852d60 error:0 in libdrm_amdgpu.so.1.0.0[7f33d2cdc000+7000] Attached should be the output given by debian's xserver-xorg-video-amdgpu bugscript -- You are receiving this mail because: You are the assignee for the bug.

1 4

Re: r600/shader: emit tessellation factors to GDS at end of TCS.
by Dieter Nützel 15 Jan '16

15 Jan '16

Hello Dave, first all the best for your newborn and your whole family! Second: What could be differend between r6xx/r7xx and EG+ (NI, here) that the below fixes the 'gsraytrace' GPU hang on the later but NOT on the former? Any ideas, hints where I could start? r6xx/r7xx do not have any TESS support as we now. So where to start? Disabling some lines of your commit and try? commit 2239f3eaff5c72c4cb1d4a5be97feb4af3d08d25 Author: Dave Airlie <airlied(a)redhat.com> Date: Mon Nov 30 15:48:22 2015 +1000 r600/shader: emit tessellation factors to GDS at end of TCS. When we are finished the shader, we read back all the tess factors from LDS and write them to special global memory storage using GDS instructions. This also handles adding NOP when GDS or ENDLOOP end the TCS. Signed-off-by: Dave Airlie <airlied(a)redhat.com> Thanks, Dieter

2 2

Lockdep warning when using REGCACHE_RBTREE
by Stefan Agner 15 Jan '16

15 Jan '16

Hi Mark, I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following warning on startup: [ 1.327284] ------------[ cut here ]------------ [ 1.332010] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0x120/0x124() [ 1.341358] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [ 1.346807] Modules linked in: [ 1.350161] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-00013-g7e569bc-dirty #41 [ 1.357851] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 1.364376] Backtrace: [ 1.366924] [<80013ba0>] (dump_backtrace) from [<80013d98>] (show_stack+0x18/0x1c) [ 1.374609] r7:80054ac4 r6:00000ac3 r5:00000009 r4:00000000 [ 1.380434] [<80013d80>] (show_stack) from [<8028eb84>] (dump_stack+0x24/0x28) [ 1.387795] [<8028eb60>] (dump_stack) from [<80021ecc>] (warn_slowpath_common+0x88/0xb4) [ 1.396021] [<80021e44>] (warn_slowpath_common) from [<80021f30>] (warn_slowpath_fmt+0x38/0x40) [ 1.404842] r8:000001fc r7:80378238 r6:024080c0 r5:8f801f00 r4:808d63fc [ 1.411743] [<80021efc>] (warn_slowpath_fmt) from [<80054ac4>] (lockdep_trace_alloc+0x120/0x124) [ 1.420654] r3:808d98e0 r2:808d63fc [ 1.424325] r4:600000d3 [ 1.426950] [<800549a4>] (lockdep_trace_alloc) from [<800dad44>] (kmem_cache_alloc+0x30/0x110) [ 1.435684] r5:8f801f00 r4:024080c0 [ 1.439380] [<800dad14>] (kmem_cache_alloc) from [<80378238>] (regcache_rbtree_write+0x138/0x504) [ 1.448374] r7:8fa1b5c0 r6:8fa14800 r5:00000218 r4:00000000 [ 1.454196] [<80378100>] (regcache_rbtree_write) from [<803773e0>] (regcache_write+0x5c/0x64) [ 1.462838] r10:8fa1b588 r9:00000001 r8:00000004 r7:00000000 r6:00000000 r5:000001fc [ 1.470882] r4:8fa14800 [ 1.473504] [<80377384>] (regcache_write) from [<80375d20>] (_regmap_raw_write+0x124/0x5fc) [ 1.481972] r7:00000000 r6:8fa1b584 r5:00000004 r4:8fa14800 [ 1.487796] [<80375bfc>] (_regmap_raw_write) from [<8037626c>] (_regmap_bus_raw_write+0x74/0x90) [ 1.496703] r10:00000000 r9:00000024 r8:00000000 r7:8fa14800 r6:00000000 r5:000001fc [ 1.504745] r4:8fa14800 [ 1.507365] [<803761f8>] (_regmap_bus_raw_write) from [<80375368>] (_regmap_write+0x60/0x9c) [ 1.515923] r7:8fa14800 r6:00000000 r5:000001fc r4:8fa14800 [ 1.521744] [<80375308>] (_regmap_write) from [<80376760>] (regmap_write+0x48/0x68) [ 1.529516] r7:000001fc r6:00000000 r5:000001fc r4:8fa14800 [ 1.535348] [<80376718>] (regmap_write) from [<803538e8>] (fsl_dcu_drm_crtc_create+0x98/0xe8) [ 1.543998] r7:000001fc r6:00000220 r5:8f9a6810 r4:00000200 [ 1.549824] [<80353850>] (fsl_dcu_drm_crtc_create) from [<80352df0>] (fsl_dcu_drm_modeset_init+0x5c/0xfc) [ 1.559522] r9:809a25ec r8:8f9a7000 r7:8f8bd410 r6:8f9a6810 r5:8f9a7000 r4:8f9a6810 [ 1.567490] [<80352d94>] (fsl_dcu_drm_modeset_init) from [<80352894>] (fsl_dcu_load+0x34/0x1d8) [ 1.576308] r7:8f8bd410 r6:8f9a6810 r5:8f9a7000 r4:8f9a7000 [ 1.582141] [<80352860>] (fsl_dcu_load) from [<803330bc>] (drm_dev_register+0xb4/0xc4) [ 1.590180] r9:809a25ec r8:8f9a7000 r7:8f8bd400 r6:00000000 r5:00000000 r4:8f9a7000 [ 1.598140] [<80333008>] (drm_dev_register) from [<80352c8c>] (fsl_dcu_drm_probe+0x254/0x2cc) [ 1.606785] r7:8f8bd400 r6:8f9a6810 r5:8f8bd410 r4:00000000 [ 1.612620] [<80352a38>] (fsl_dcu_drm_probe) from [<80362d3c>] (platform_drv_probe+0x58/0xb4) [ 1.621270] r8:00000000 r7:fffffdfb r6:80a0aee8 r5:8f8bd410 r4:ffffffed [ 1.628159] [<80362ce4>] (platform_drv_probe) from [<803611c8>] (driver_probe_device+0x210/0x304) [ 1.637153] r7:80a0aee8 r6:00000000 r5:8f8bd410 r4:81242468 [ 1.642971] [<80360fb8>] (driver_probe_device) from [<80361358>] (__driver_attach+0x9c/0xa0) [ 1.651530] r9:809a25ec r8:000000cd r7:00000000 r6:8f8bd444 r5:80a0aee8 r4:8f8bd410 [ 1.659503] [<803612bc>] (__driver_attach) from [<8035f41c>] (bus_for_each_dev+0x70/0xa4) [ 1.667801] r7:00000000 r6:803612bc r5:80a0aee8 r4:00000000 [ 1.673639] [<8035f3ac>] (bus_for_each_dev) from [<80360c10>] (driver_attach+0x24/0x28) [ 1.681763] r6:80a0b7f0 r5:8fa19580 r4:80a0aee8 [ 1.686517] [<80360bec>] (driver_attach) from [<8036083c>] (bus_add_driver+0x1a8/0x220) [ 1.694657] [<80360694>] (bus_add_driver) from [<80361bfc>] (driver_register+0x80/0x100) [ 1.702869] r7:8fa16a40 r6:809eb3e0 r5:809bc6fc r4:80a0aee8 [ 1.708685] [<80361b7c>] (driver_register) from [<80362c60>] (__platform_driver_register+0x48/0x50) [ 1.717855] r5:809bc6fc r4:80a0b7f0 [ 1.721543] [<80362c18>] (__platform_driver_register) from [<809bc718>] (fsl_dcu_drm_platform_driver_init+0x1c/0x20) [ 1.732202] r5:809bc6fc r4:809eb3e0 [ 1.735894] [<809bc6fc>] (fsl_dcu_drm_platform_driver_init) from [<800096b4>] (do_one_initcall+0x98/0x1e4) [ 1.745689] [<8000961c>] (do_one_initcall) from [<809a2e3c>] (kernel_init_freeable+0x138/0x1dc) [ 1.754510] r10:809d6850 r9:809a25ec r8:000000cd r7:80a40d40 r6:80a40d40 r5:00000006 [ 1.762553] r4:809e5840 [ 1.765175] [<809a2d04>] (kernel_init_freeable) from [<8073ef00>] (kernel_init+0x18/0xf0) [ 1.773468] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8073eee8 [ 1.781506] r4:80a40d40 [ 1.784128] [<8073eee8>] (kernel_init) from [<8000f9d0>] (ret_from_fork+0x14/0x24) [ 1.791810] r5:8073eee8 r4:00000000 [ 1.795539] ---[ end trace e76a00401296776a ]--- I do use REGCACHE_RBTREE along with regmap_write from within the probe code path of the driver. This ultimately leads to an allocation. However, what I don't understand is why the allocation is leading to that error. The actual allocation happens in regcache_rbtree_node_alloc and seems to be a rather common kzalloc with GFP_KERNEL... The comment in __lockdep_trace_alloc says: "Oi! Can't be having __GFP_FS allocations with IRQs disabled.". Not sure if this is a Linux 4.4 issue, Fabio Estevam reported a similar issue just recently, not sure if that is related: https://lkml.org/lkml/2016/1/11/284 -- Stefan

3 6

[PATCH 0/7] Add gpu reset to amdgpu
by Alex Deucher 15 Jan '16

15 Jan '16

This patch set gets basic gpu reset working with amdgpu. It's only been tested via debugfs. It still needs to be integrated into the lockup detection in the driver to be used for runtime lockup resets. Alex Deucher (7): drm/amdgpu: fix tonga smu resume drm/amdgpu: Add some tweaks to gfx 8 soft reset drm/amdgpu: clean up asic level reset for CI drm/amdgpu: clean up asic level reset for VI drm/amdgpu: post card after hard reset drm/amdgpu: add a debugfs property to trigger a GPU reset drm/amdgpu: drop hard_reset module parameter drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 - drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 20 +- drivers/gpu/drm/amd/amdgpu/cik.c | 308 +---------------------- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 23 +- drivers/gpu/drm/amd/amdgpu/tonga_dpm.c | 17 +- drivers/gpu/drm/amd/amdgpu/vi.c | 385 +---------------------------- 8 files changed, 54 insertions(+), 707 deletions(-) -- 2.5.0

1 7

DRM support in Android
by vijay kumar 15 Jan '16

15 Jan '16

Hii all, I want to know some information regarding DRI and DRM support in android.Does Android uses DRI drivers in MESA for Direct rendering.Can DRI drivers alone can be used without DRM ? I am pretty confused that how Direct rendering is performed in android whether by DRI or some other method.Struggling with this problem since many days but did n't find any answer .Please do help me. Thanks and Regards.

4 5

[Bug 106901] Brightness / WIFI Key does not generate any events
by bugzilla-daemon＠bugzilla.kernel.org 15 Jan '16

15 Jan '16

https://bugzilla.kernel.org/show_bug.cgi?id=106901 --- Comment #28 from Roman Gruber <roman.gruber(a)gmx.at> --- lsmod Module Size Used by nvidia_modeset 721045 3 nvidia 9922734 59 nvidia_modeset intel_powerclamp 7094 0 xhci_pci 3818 0 xhci_hcd 86326 1 xhci_pci drm 238337 3 nvidia iTCO_wdt 5540 0 ehci_pci 3679 0 iTCO_vendor_support 1960 1 iTCO_wdt ehci_hcd 35048 1 ehci_pci pcspkr 2035 0 input_leds 2894 0 Newest binary nvidia-driver in use ASUS-G75VW roman # qlist -Iv nvidia-drivers x11-drivers/nvidia-drivers-361.18 -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 106901] Brightness / WIFI Key does not generate any events
by bugzilla-daemon＠bugzilla.kernel.org 15 Jan '16

15 Jan '16

https://bugzilla.kernel.org/show_bug.cgi?id=106901 --- Comment #27 from Roman Gruber <roman.gruber(a)gmx.at> --- Linux ASUS-G75VW 4.4.0-gentoo_14-01-2016 #1 SMP Thu Jan 14 19:15:47 CET 2016 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux same behaviour -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016