dri-devel May 2018

dri-devel@lists.freedesktop.org

268 participants
1833 discussions

[PATCH] drm/nouveau: Fix deadlock in nv50_mstm_register_connector()
by Lyude Paul 02 May '18

02 May '18

Currently; we're grabbing all of the modesetting locks before adding MST connectors to fbdev. This isn't actually necessary, and causes a deadlock as well: ====================================================== WARNING: possible circular locking dependency detected 4.17.0-rc3Lyude-Test+ #1 Tainted: G O ------------------------------------------------------ kworker/1:0/18 is trying to acquire lock: 00000000c832f62d (&helper->lock){+.+.}, at: drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] but task is already holding lock: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (crtc_ww_class_mutex){+.+.}: ww_mutex_lock+0x43/0x80 drm_modeset_lock+0x71/0x130 [drm] drm_helper_probe_single_connector_modes+0x7d/0x6b0 [drm_kms_helper] drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #2 (crtc_ww_class_acquire){+.+.}: drm_helper_probe_single_connector_modes+0x58/0x6b0 [drm_kms_helper] drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #1 (&dev->mode_config.mutex){+.+.}: drm_setup_crtcs+0x10c/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (&helper->lock){+.+.}: __mutex_lock+0x70/0x9d0 drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] nv50_mstm_register_connector+0x2c/0x50 [nouveau] drm_dp_add_port+0x2f5/0x420 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_add_port+0x33f/0x420 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper] drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper] process_one_work+0x20d/0x650 worker_thread+0x3a/0x390 kthread+0x11e/0x140 ret_from_fork+0x3a/0x50 other info that might help us debug this: Chain exists of: &helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(crtc_ww_class_mutex); lock(crtc_ww_class_acquire); lock(crtc_ww_class_mutex); lock(&helper->lock); *** DEADLOCK *** 5 locks held by kworker/1:0/18: #0: 000000004a05cd50 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x187/0x650 #1: 00000000601c11d1 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x187/0x650 #2: 00000000586ca0df (&dev->mode_config.mutex){+.+.}, at: drm_modeset_lock_all+0x3a/0x1b0 [drm] #3: 00000000d3ca0ffa (crtc_ww_class_acquire){+.+.}, at: drm_modeset_lock_all+0x44/0x1b0 [drm] #4: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm] stack backtrace: CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G O 4.17.0-rc3Lyude-Test+ #1 Hardware name: Gateway FX6840/FX6840, BIOS P01-A3 05/17/2010 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] Call Trace: dump_stack+0x85/0xcb print_circular_bug.isra.38+0x1ce/0x1db __lock_acquire+0x128f/0x1350 ? lock_acquire+0x9f/0x200 ? lock_acquire+0x9f/0x200 ? __ww_mutex_lock.constprop.13+0x8f/0x1000 lock_acquire+0x9f/0x200 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] __mutex_lock+0x70/0x9d0 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] ? ww_mutex_lock+0x43/0x80 ? _cond_resched+0x15/0x30 ? ww_mutex_lock+0x43/0x80 ? drm_modeset_lock+0xb2/0x130 [drm] ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] nv50_mstm_register_connector+0x2c/0x50 [nouveau] drm_dp_add_port+0x2f5/0x420 [drm_kms_helper] ? mark_held_locks+0x50/0x80 ? kfree+0xcf/0x2a0 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper] ? trace_hardirqs_on_caller+0xed/0x180 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_add_port+0x33f/0x420 [drm_kms_helper] ? nouveau_connector_aux_xfer+0x7c/0xb0 [nouveau] ? find_held_lock+0x2d/0x90 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper] ? __mutex_unlock_slowpath+0x3b/0x280 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper] drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper] process_one_work+0x20d/0x650 worker_thread+0x3a/0x390 ? process_one_work+0x650/0x650 kthread+0x11e/0x140 ? kthread_create_worker_on_cpu+0x50/0x50 ret_from_fork+0x3a/0x50 Taking example from i915, the only time we need to hold any modesetting locks is when changing the port on the mstc, and in that case we only need to hold the connection mutex. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Karol Herbst <kherbst(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 8bd739cfd00d..2b3ccd850750 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -3264,10 +3264,11 @@ nv50_mstm_destroy_connector(struct drm_dp_mst_topology_mgr *mgr, drm_connector_unregister(&mstc->connector); - drm_modeset_lock_all(drm->dev); drm_fb_helper_remove_one_connector(&drm->fbcon->helper, &mstc->connector); + + drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL); mstc->port = NULL; - drm_modeset_unlock_all(drm->dev); + drm_modeset_unlock(&drm->dev->mode_config.connection_mutex); drm_connector_unreference(&mstc->connector); } @@ -3277,9 +3278,7 @@ nv50_mstm_register_connector(struct drm_connector *connector) { struct nouveau_drm *drm = nouveau_drm(connector->dev); - drm_modeset_lock_all(drm->dev); drm_fb_helper_add_one_connector(&drm->fbcon->helper, connector); - drm_modeset_unlock_all(drm->dev); drm_connector_register(connector); } -- 2.14.3

1 0

[Bug 106355] Strange artifacts when using Chromium with hardware acceleration
by bugzilla-daemon＠freedesktop.org 02 May '18

02 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=106355 Timothy Arceri <t_arceri(a)yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Timothy Arceri <t_arceri(a)yahoo.com.au> --- *** This bug has been marked as a duplicate of bug 104347 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
by bugzilla-daemon＠freedesktop.org 02 May '18

02 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #68 from MirceaKitsune <sonichedgehog_hyperblast00(a)yahoo.com> --- Created attachment 139283 --> https://bugs.freedesktop.org/attachment.cgi?id=139283&action=edit Output of: watch --interval 0.1 sensors (In reply to H4nN1baL from comment #66) My BIOS offers no options regarding GART and Spread Spectrum as far as I recall. Here is my exact motherboard model, in case anyone has extra info on what its available BIOS settings mean which I may have missed. https://www.gigabyte.com/Motherboard/GA-X58A-UD7-rev-10 (In reply to iive from comment #67) That is indeed a difference: Everyone else reporting those crashes seems to be able to record a Kernel panic, but in my case the system records nothing as it fundamentally stops functioning at that very moment. I logged into SSH from my other machine and ran "watch --interval 0.1 sensors". Attached are my readings at most 0.1 seconds before the freeze, which seem to capture every relevant voltage and temperature available. Obviously there are no fans in slots 2 and 4 which is why they show 0 RPM. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.
by Eric Anholt 02 May '18

02 May '18

In the cleanup, I didn't notice that we needed to dereference the connector for the bus_format. Fix the regression by looking up the first (and only) connector attached to us, and assume that its bus_format is what we want. Some day it would be good to have that part of display_info attached to the bridge, instead. Signed-off-by: Eric Anholt <eric(a)anholt.net> Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.") Cc: Boris Brezillon <boris.brezillon(a)bootlin.com> --- drivers/gpu/drm/vc4/vc4_dpi.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c index 72c9dbd81d7f..88783e143cc2 100644 --- a/drivers/gpu/drm/vc4/vc4_dpi.c +++ b/drivers/gpu/drm/vc4/vc4_dpi.c @@ -96,7 +96,6 @@ struct vc4_dpi { struct platform_device *pdev; struct drm_encoder *encoder; - struct drm_connector *connector; void __iomem *regs; @@ -164,14 +163,31 @@ static void vc4_dpi_encoder_disable(struct drm_encoder *encoder) static void vc4_dpi_encoder_enable(struct drm_encoder *encoder) { + struct drm_device *dev = encoder->dev; struct drm_display_mode *mode = &encoder->crtc->mode; struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder); struct vc4_dpi *dpi = vc4_encoder->dpi; + struct drm_connector_list_iter conn_iter; + struct drm_connector *connector = NULL, *connector_scan; u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE; int ret; - if (dpi->connector->display_info.num_bus_formats) { - u32 bus_format = dpi->connector->display_info.bus_formats[0]; + /* Look up the connector attached to DPI so we can get the + * bus_format. Ideally the bridge would tell us the + * bus_format we want, but it doesn't yet, so assume that it's + * uniform throughout the bridge chain. + */ + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector_scan, &conn_iter) { + if (connector_scan->encoder == encoder) { + connector = connector_scan; + break; + } + } + drm_connector_list_iter_end(&conn_iter); + + if (connector && connector->display_info.num_bus_formats) { + u32 bus_format = connector->display_info.bus_formats[0]; switch (bus_format) { case MEDIA_BUS_FMT_RGB888_1X24: @@ -199,6 +215,9 @@ static void vc4_dpi_encoder_enable(struct drm_encoder *encoder) DRM_ERROR("Unknown media bus format %d\n", bus_format); break; } + } else { + /* Default to 24bit if no connector found. */ + dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB, DPI_FORMAT); } if (mode->flags & DRM_MODE_FLAG_NHSYNC) @@ -264,7 +283,7 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi) return ret; } - if (panel) + if (panel) bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI); return drm_bridge_attach(dpi->encoder, bridge, NULL); -- 2.16.2

3 3

[PULL] drm-misc-fixes
by Sean Paul 02 May '18

02 May '18

Hi Dave, A couple of CS 101 "Gotcha!" fixes for you this week. One for a reference count, and one for a memory leak. Both are cc: stable. drm-misc-fixes-2018-05-02: vc4: Fix bo refcounts during async commits (Boris) vga-dac: Fix edid memory leak (Sean) Cc: Boris Brezillon <boris.brezillon(a)bootlin.com> Cc: Sean Paul <seanpaul(a)chromium.org> Cheers, Sean The following changes since commit 1f6b8eef11c3d097bc8a6b2bbb868eb47ec6f7d8: drm/edid: Reset more of the display info (2018-04-25 15:03:13 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-02 for you to fetch changes up to 49ceda9de2da4d1827941d06701f3017c27c1855: drm/bridge: vga-dac: Fix edid memory leak (2018-05-02 15:09:21 -0400) ---------------------------------------------------------------- vc4: Fix bo refcounts during async commits (Boris) vga-dac: Fix edid memory leak (Sean) Cc: Boris Brezillon <boris.brezillon(a)bootlin.com> Cc: Sean Paul <seanpaul(a)chromium.org> ---------------------------------------------------------------- Boris Brezillon (1): drm/vc4: Make sure vc4_bo_{inc,dec}_usecnt() calls are balanced Sean Paul (1): drm/bridge: vga-dac: Fix edid memory leak drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 ++- drivers/gpu/drm/vc4/vc4_crtc.c | 46 ++++++++++++++++++++++++++++++++++- 2 files changed, 48 insertions(+), 2 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS

1 0

[PATCH] drm/bridge: vga-dac: Fix edid memory leak
by Sean Paul 02 May '18

02 May '18

edid should be freed once it's finished being used. Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support") Cc: Rob Herring <robh(a)kernel.org> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Maxime Ripard <maxime.ripard(a)free-electrons.com> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: <stable(a)vger.kernel.org> # v4.9+ Signed-off-by: Sean Paul <seanpaul(a)chromium.org> --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 498d5948d1a8..9837c8d69e69 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -56,7 +56,9 @@ static int dumb_vga_get_modes(struct drm_connector *connector) } drm_mode_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + ret = drm_add_edid_modes(connector, edid); + kfree(edid); + return ret; fallback: /* -- Sean Paul, Software Engineer, Google / Chromium OS

3 3

[PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded
by Daniel Vetter 02 May '18

02 May '18

This came up in discussions when reviewing drm patches. Cc: Eric Anholt <eric(a)anholt.net> Cc: linux-doc(a)vger.kernel.org Cc: Jonathan Corbet <corbet(a)lwn.net> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> -- Aside: I wonder whether we shouldn't move this to some other place and rst-ify it? Any good suggestions? -Daniel --- Documentation/ioctl/botching-up-ioctls.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt index d02cfb48901c..883fb034bd04 100644 --- a/Documentation/ioctl/botching-up-ioctls.txt +++ b/Documentation/ioctl/botching-up-ioctls.txt @@ -73,7 +73,9 @@ will have a second iteration or at least an extension for any given interface. future extensions is going right down the gutters since someone will submit an ioctl struct with random stack garbage in the yet unused parts. Which then bakes in the ABI that those fields can never be used for anything else - but garbage. + but garbage. This is also the reason why you must explicitly pad all + structures, even if you never use them in an array - the padding the compiler + might insert could contain garbage. * Have simple testcases for all of the above. -- 2.17.0

2 1

[PATCH v3] drm/i915: Disable some extra clang warnings
by Matthias Kaehlcke 02 May '18

02 May '18

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also enabled some additional clang-only warnings, as a result building i915 with clang currently is extremely noisy. For now also disable the clang warnings sign-compare, sometimes-uninitialized, unneeded-internal-declaration and initializer-overrides. If desired they can be re-enabled after the code has been fixed. Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> --- Changes in v3: - don't disable -Wunneeded-internal-declaration , the only occurrence can be fixed in the code - removed 'Fixes' tag, since backporting is not necessary drivers/gpu/drm/i915/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 9bee52a949a9..dfe01452c8d1 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -18,6 +18,10 @@ subdir-ccflags-y += $(call cc-disable-warning, type-limits) subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers) subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough) subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable) +# clang warnings +subdir-ccflags-y += $(call cc-disable-warning, sign-compare) +subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized) +subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides) subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror # Fine grained warnings disable -- 2.17.0.441.gb46fe60e1d-goog

2 2

[Bug 106355] Strange artifacts when using Chromium with hardware acceleration
by bugzilla-daemon＠freedesktop.org 02 May '18

02 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=106355 --- Comment #2 from Norbert Klar <klarnorbert(a)gmail.com> --- Yep, except in my case, it's only happening with Chromium. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 106355] Strange artifacts when using Chromium with hardware acceleration
by bugzilla-daemon＠freedesktop.org 02 May '18

02 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=106355 --- Comment #1 from Timothy Arceri <t_arceri(a)yahoo.com.au> --- Looks a bit like bug 105910 -- You are receiving this mail because: You are the assignee for 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 May 2018