dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH 0/6] Fix the debugfs splat from mock selftests (v3)
by Jason Ekstrand 22 Jul '21

22 Jul '21

This patch series fixes a miscellaneous collection of bugs that all add up to all our mock selftests throwing dmesg warnings in CI. As can be seen from "drm/i915: Use a table for i915_init/exit", it's especially fun since those warnings don't always show up in the selftests but can show up in other random IGTs depending on test execution order. Jason Ekstrand (6): drm/i915: Call i915_globals_exit() after i915_pmu_exit() drm/i915: Call i915_globals_exit() if pci_register_device() fails drm/i915: Use a table for i915_init/exit (v2) drm/ttm: Force re-init if ttm_global_init() fails drm/ttm: Initialize debugfs from ttm_global_init() drm/i915: Make the kmem slab for i915_buddy_block a global drivers/gpu/drm/i915/i915_buddy.c | 44 ++++++-- drivers/gpu/drm/i915/i915_buddy.h | 3 +- drivers/gpu/drm/i915/i915_globals.c | 6 +- drivers/gpu/drm/i915/i915_pci.c | 104 ++++++++++++------ drivers/gpu/drm/i915/i915_perf.c | 3 +- drivers/gpu/drm/i915/i915_perf.h | 2 +- drivers/gpu/drm/i915/i915_pmu.c | 4 +- drivers/gpu/drm/i915/i915_pmu.h | 4 +- .../gpu/drm/i915/selftests/i915_selftest.c | 4 +- drivers/gpu/drm/ttm/ttm_device.c | 14 +++ drivers/gpu/drm/ttm/ttm_module.c | 16 --- 11 files changed, 136 insertions(+), 68 deletions(-) -- 2.31.1

3 12

Re: refactor the i915 GVT support
by Zhenyu Wang 22 Jul '21

22 Jul '21

On 2021.07.21 17:53:34 +0200, Christoph Hellwig wrote: > Hi all, > > the GVT code in the i915 is a bit of a mess right now due to strange > abstractions and lots of indirect calls. This series refactors various > bits to clean that up. The main user visible change is that almost all > of the GVT code moves out of the main i915 driver and into the kvmgt > module. > The reason we isolated hypervisor specific code from core vgpu emulation is to make multiple hypervisor support possible. Yes, we do have Xen support but never got way into upstream...And we also have third party hypervisors which leverage gvt function through current hypervisor interface. Sorry I may not have more time to check in details for now, but some of them look fine to me. I'll review more after vacation or let Zhi check details. Thanks! > Tested on my Thinkpad with a Kaby Lake CPU and integrated graphics. > > Git tree: > > git://git.infradead.org/users/hch/misc.git i915-gvt > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-gvt > > Diffstat: > b/drivers/gpu/drm/i915/Kconfig | 31 > b/drivers/gpu/drm/i915/Makefile | 30 > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 > b/drivers/gpu/drm/i915/gvt/cfg_space.c | 89 -- > b/drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 > b/drivers/gpu/drm/i915/gvt/dmabuf.c | 36 > b/drivers/gpu/drm/i915/gvt/execlist.c | 12 > b/drivers/gpu/drm/i915/gvt/gtt.c | 55 - > b/drivers/gpu/drm/i915/gvt/gvt.c | 100 -- > b/drivers/gpu/drm/i915/gvt/gvt.h | 132 ++- > b/drivers/gpu/drm/i915/gvt/interrupt.c | 38 - > b/drivers/gpu/drm/i915/gvt/kvmgt.c | 634 ++++------------- > b/drivers/gpu/drm/i915/gvt/mmio.c | 4 > b/drivers/gpu/drm/i915/gvt/opregion.c | 148 --- > b/drivers/gpu/drm/i915/gvt/page_track.c | 8 > b/drivers/gpu/drm/i915/gvt/scheduler.c | 37 > b/drivers/gpu/drm/i915/gvt/trace.h | 2 > b/drivers/gpu/drm/i915/gvt/vgpu.c | 22 > b/drivers/gpu/drm/i915/i915_drv.h | 7 > b/drivers/gpu/drm/i915/i915_params.c | 2 > b/drivers/gpu/drm/i915/intel_gvt.c | 64 + > b/drivers/gpu/drm/i915/intel_gvt.h | 4 > drivers/gpu/drm/i915/gvt/Makefile | 9 > drivers/gpu/drm/i915/gvt/hypercall.h | 82 -- > drivers/gpu/drm/i915/gvt/mpt.h | 400 ---------- > 25 files changed, 541 insertions(+), 1413 deletions(-)

1 0

[PATCH 11/54] dt-bindings: display: simple-bridge: Add corpro, gm7123 compatible
by Maxime Ripard 22 Jul '21

22 Jul '21

The corpro,gm7123 was in use in a DT but was never properly documented, let's add it. Cc: dri-devel(a)lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- Changes from v1: - Removed the dumb-vga-dac compatible from the list --- .../devicetree/bindings/display/bridge/simple-bridge.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index 6c7b577fd471..43cf4df9811a 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -22,6 +22,9 @@ properties: - ti,ths8134a - ti,ths8134b - const: ti,ths8134 + - items: + - const: corpro,gm7123 + - const: adi,adv7123 - enum: - adi,adv7123 - dumb-vga-dac -- 2.31.1

2 2

[PATCH v8 0/5] drm: address potential UAF bugs with drm_master ptrs
by Desmond Cheong Zhi Xi 22 Jul '21

22 Jul '21

Hi, In the previous thread on this series we decided to remove a patch that was violating a lockdep requirement in drm_lease. In addition to this change, I took a closer look at the CI logs for the Basic Acceptance Tests and noticed that another regression was introduced. The new patch 2 is a response to this. Overall, this series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f8… The series is broken up into five patches: 1. Move a call to drm_is_current_master() out from a section locked by &dev->mode_config.mutex in drm_mode_getconnector(). This patch does not apply to stable. 2. Move a call to drm_is_current_master() out from the RCU read-side critical section in drm_clients_info(). 3. Implement a locked version of drm_is_current_master() function that's used within drm_auth.c. 4. Serialize drm_file.master by introducing a new spinlock that's held whenever the value of drm_file.master changes. 5. Identify areas in drm_lease.c where pointers to struct drm_master are dereferenced, and ensure that the master pointers are not freed during use. v7 -> v8: - Remove the patch that moves the call to _drm_lease_held out from the section locked by &dev->mode_config.idr_mutex in __drm_mode_object_find. This patch violated an existing lockdep requirement as reported by the intel-gfx CI. - Added a new patch that moves a call to drm_is_current_master out from the RCU critical section in drm_clients_info. This was reported by the intel-gfx CI. v6 -> v7: - Modify code alignment as suggested by the intel-gfx CI. - Add a new patch to the series that adds a new lock to serialize drm_file.master, in response to the lockdep splat by the intel-gfx CI. - Update drm_file_get_master to use the new drm_file.master_lock instead of drm_device.master_mutex, in response to the lockdep splat by the intel-gfx CI. v5 -> v6: - Add a new patch to the series that moves the call to _drm_lease_held out from the section locked by &dev->mode_config.idr_mutex in __drm_mode_object_find. - Clarify the kerneldoc for dereferencing drm_file.master, as suggested by Daniel Vetter. - Refactor error paths with goto labels so that each function only has a single drm_master_put(), as suggested by Emil Velikov. - Modify comparisons to NULL into "!master", as suggested by the intel-gfx CI. v4 -> v5: - Add a new patch to the series that moves the call to drm_is_current_master in drm_mode_getconnector out from the section locked by &dev->mode_config.mutex. - Additionally, added a missing semicolon to the patch, caught by the intel-gfx CI. v3 -> v4: - Move the call to drm_is_current_master in drm_mode_getconnector out from the section locked by &dev->mode_config.mutex. As suggested by Daniel Vetter. This avoids a circular lock lock dependency as reported here https://patchwork.freedesktop.org/patch/440406/ - Inside drm_is_current_master, instead of grabbing &fpriv->master->dev->master_mutex, we grab &fpriv->minor->dev->master_mutex to avoid dereferencing a null ptr if fpriv->master is not set. - Modify kerneldoc formatting for drm_file.master, as suggested by Daniel Vetter. - Additionally, add a file_priv->master NULL check inside drm_file_get_master, and handle the NULL result accordingly in drm_lease.c. As suggested by Daniel Vetter. v2 -> v3: - Move the definition of drm_is_current_master and the _locked version higher up in drm_auth.c to avoid needing a forward declaration of drm_is_current_master_locked. As suggested by Daniel Vetter. - Instead of leaking drm_device.master_mutex into drm_lease.c to protect drm_master pointers, add a new drm_file_get_master() function that returns drm_file->master while increasing its reference count, to prevent drm_file->master from being freed. As suggested by Daniel Vetter. v1 -> v2: - Move the lock and assignment before the DRM_DEBUG_LEASE in drm_mode_get_lease_ioctl, as suggested by Emil Velikov. Desmond Cheong Zhi Xi (5): drm: avoid circular locks in drm_mode_getconnector drm: avoid blocking in drm_clients_info's rcu section drm: add a locked version of drm_is_current_master drm: serialize drm_file.master with a new spinlock drm: protect drm_master pointers in drm_lease.c drivers/gpu/drm/drm_auth.c | 93 ++++++++++++++++++++++++--------- drivers/gpu/drm/drm_connector.c | 5 +- drivers/gpu/drm/drm_debugfs.c | 3 +- drivers/gpu/drm/drm_file.c | 1 + drivers/gpu/drm/drm_lease.c | 81 +++++++++++++++++++++------- include/drm/drm_auth.h | 1 + include/drm/drm_file.h | 18 +++++-- 7 files changed, 152 insertions(+), 50 deletions(-) -- 2.25.1

2 11

[PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
by Christian König 22 Jul '21

22 Jul '21

Turned out that doing this in vmw_ttm_destroy() is to late. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index b0973c27e774..904031d03dbe 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev, struct ttm_tt *ttm) struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, dma_ttm); - vmw_ttm_unbind(bdev, ttm); ttm_tt_destroy_common(bdev, ttm); vmw_ttm_unmap_dma(vmw_be); - if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent) - ttm_tt_fini(&vmw_be->dma_ttm); - else - ttm_tt_fini(ttm); - + ttm_tt_fini(ttm); if (vmw_be->mob) vmw_mob_destroy(vmw_be->mob); @@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev, dma_ttm); unsigned int i; + vmw_ttm_unbind(bdev, ttm); + if (vmw_tt->mob) { vmw_mob_destroy(vmw_tt->mob); vmw_tt->mob = NULL; -- 2.25.1

2 6

[PATCH 0/4] Nuke legacy hw_id
by Lucas De Marchi 22 Jul '21

22 Jul '21

Motivated by my review in https://patchwork.freedesktop.org/patch/443857/?series=92135&rev=5 I went to look why we needed the additional hw_id fields. It turns out we don't, but we kept adding new IDs to keep it consistent. Now that with the extra media engines we would just leave than zero'ed, let's refactor the code so we don't keep them around: they aren't used since GRAPHICS_VER == 8. I'd say last patch is a stretch due to the use of _PICK() and hardcoding the map, but to me it seems to avoid making it more complex elsewhere. Lucas De Marchi (4): drm/i915/gt: fix platform prefix drm/i915/gt: nuke unused legacy engine hw_id drm/i915/gt: rename legacy engine->hw_id to engine->gen6_hw_id drm/i915/gt: nuke gen6_hw_id drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 ---------- drivers/gpu/drm/i915/gt/intel_engine_types.h | 12 ------------ drivers/gpu/drm/i915/gt/intel_gt.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h | 4 +++- 4 files changed, 5 insertions(+), 25 deletions(-) -- 2.31.1

4 16

[PATCH v2 0/3] Add ilitek ili9341 panel driver
by dillon.minfei＠gmail.com 22 Jul '21

22 Jul '21

From: Dillon Min <dillon.minfei(a)gmail.com> Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts but, the panel driver didn't get accepted from mainline. it's time to submit patch fot it. This driver can support two different interface by different dts bindings: - spi+dpi, use spi to configure register, dpi for graphic data. st,sf-tc240t-9370-t - only spi, just like tiny/ili9341.c (actually, this part is copy from tiny) adafruit,yx240qv29 I submited the first patch last year, you can find it at [1]. this patch has one major difference from that one, which is replace the low level communication way, from spi_sync() to mipi_dbi_{command, command_stackbuf}() interface, referred from Linus's patch [2]. both the two dpi/dbi interface was tested on stm32f429-disco board, if anyone want to verify this patch, you need apply the clk patch for this board first, you can get it from [3] [1] "drm/panel: Add ilitek ili9341 panel driver" https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.minfei… [2] "drm/panel: s6e63m0: Switch to DBI abstraction for SPI" https://lore.kernel.org/dri-devel/20210611214243.669892-1-linus.walleij@lin… [3] https://lore.kernel.org/lkml/1590378348-8115-6-git-send-email-dillon.minfei… v2: - replace vcc regulator to bulk regulators in driver, from linus suggestion. - fix dtbs_check warnings on ili9341 dts binding check. - add bulk regulation node in ilitek,ili9341.yaml. v1 link: https://lore.kernel.org/lkml/1626430843-23823-1-git-send-email-dillon.minfe… Dillon Min (3): dt-bindings: display: panel: Add ilitek ili9341 panel bindings ARM: dts: stm32: fix dtbs_check warning on ili9341 dts binding drm/panel: Add ilitek ili9341 panel driver .../bindings/display/panel/ilitek,ili9341.yaml | 78 +++ arch/arm/boot/dts/stm32f429-disco.dts | 2 +- drivers/gpu/drm/panel/Kconfig | 12 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 778 +++++++++++++++++++++ 5 files changed, 870 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c -- 2.7.4

6 18

[PATCH v1 0/7] drm/bridge: Drop deprecated functions
by Sam Ravnborg 22 Jul '21

22 Jul '21

Over time we have accumulated some deprecated functions etc. in drm_bridge. This patch-set starts to move over to the atomic variants and deletes what is not used anymore. There was only one user of the non-atomic drm_bridge_chain functions in parade-ps8640 - migrate it to the atomic variants and delete the non-atomic drm_bridge_chain functions. There was only one user of drm_bridge_chain_mode_fixup in mediatk. The use in the mediatek driver was wrong and with the single user gone we could also delete this function. Added a few todo items. Next step is to migrate the easy bridge drivers to use the atomic variants of drm_bridge_funcs operations. The easy ones are the drivers wihtout mode_set or mode_fixup. I have something typed up already, but wanted feedback on this patchset before sending out additional patches. Sam Sam Ravnborg (7): drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs drm/bridge: Drop unused drm_bridge_chain functions drm/bridge: Add drm_bridge_new_crtc_state() helper drm/bridge: lontium-lt9611: Use atomic variants of drm_bridge_funcs drm/mediatek: Drop chain_mode_fixup call in mode_valid() drm/bridge: Drop drm_bridge_chain_mode_fixup drm/todo: Add bridge related todo items Documentation/gpu/todo.rst | 47 ++++++++++ drivers/gpu/drm/bridge/lontium-lt9611.c | 69 ++++++--------- drivers/gpu/drm/bridge/parade-ps8640.c | 14 +-- drivers/gpu/drm/drm_atomic.c | 34 ++++++++ drivers/gpu/drm/drm_bridge.c | 147 -------------------------------- drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 --- include/drm/drm_atomic.h | 3 + include/drm/drm_bridge.h | 31 ------- 8 files changed, 119 insertions(+), 237 deletions(-)

2 14

[PATCH] drm: document drm_property_enum.value for bitfields
by Simon Ser 22 Jul '21

22 Jul '21

When a property has the type DRM_MODE_PROP_BITMASK, the value field stores a bitshift, not a bitmask, which can be surprising. Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Leandro Ribeiro <leandro.ribeiro(a)collabora.com> --- include/drm/drm_property.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h index bbf5c1fdd7b0..f3ea7f97f372 100644 --- a/include/drm/drm_property.h +++ b/include/drm/drm_property.h @@ -37,6 +37,11 @@ * * For enumeration and bitmask properties this structure stores the symbolic * decoding for each value. This is used for example for the rotation property. + * + * If the property has the type &DRM_MODE_PROP_BITMASK, @value stores a + * bitshift, not a bitmask. In other words, the enum entry is enabled if the + * bit number @value is set in the property's value. This enum entry has the + * bitmask ``1 << value``. */ struct drm_property_enum { uint64_t value; -- 2.32.0

3 2

[Bug 213053] New: WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD Radeon 6700XT
by bugzilla-daemon＠bugzilla.kernel.org 22 Jul '21

22 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=213053 Bug ID: 213053 Summary: WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD Radeon 6700XT Product: Drivers Version: 2.5 Kernel Version: 5.12.3 Hardware: All 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: andrewd18(a)gmail.com Regression: No Created attachment 296743 --> https://bugzilla.kernel.org/attachment.cgi?id=296743&action=edit Full dmesg 2021-05-13 I recently managed to snag a Gigabyte "Eagle 12G" Radeon 6700 XT. I am running latest Debian Testing with a 5.12.3 kernel (config based off Debian defaults) and latest linux-firmware from git. Upon installing the card into my system and booting, it outputs the warning below into kern.log. The UI is 3D accellerated, there are no errors or warnings in Xorg.log, but there is some graphical corruption and tearing in some games or on KDE's panels that disappears when the object is repainted. Neither this WARNING nor the corruption occurs when when I plug in my previous video card, a Radeon Vega 64. Please let me know if I can provide more information or test something. [ 5.481569] ------------[ cut here ]------------ [ 5.481570] WARNING: CPU: 6 PID: 165 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c:959 dcn30_set_hubp_blank+0x214/0x220 [amdgpu] [ 5.481725] Modules linked in: hid_generic(E) usbhid(E) hid(E) sd_mod(E) t10_pi(E) amdgpu(E+) gpu_sched(E) drm_ttm_helper(E) ttm(E) drm_kms_helper(E) xhci_pci(E) ahci(E) cec(E) xhci_pci_renesas(E) mxm_wmi(E) crc32_pclmul(E) crc32c_intel(E) igb(E) libahci(E) xhci_hcd(E) i2c_piix4(E) dca(E) drm(E) libata(E) i2c_algo_bit(E) usbcore(E) scsi_mod(E) wmi(E) gpio_amdpt(E) gpio_generic(E) button(E) [ 5.481736] CPU: 6 PID: 165 Comm: systemd-udevd Tainted: G E 5.12.3 #69 [ 5.481738] Hardware name: System manufacturer System Product Name/PRIME X470-PRO, BIOS 5837 02/01/2021 [ 5.481739] RIP: 0010:dcn30_set_hubp_blank+0x214/0x220 [amdgpu] [ 5.481879] Code: 31 f6 48 8b 07 48 8b 40 50 e8 58 c5 ea ed 48 8b 9b d0 02 00 00 48 85 db 75 df eb 8c 0f 0b e9 46 ff ff ff 0f 0b e9 be fe ff ff <0f> 0b e9 42 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 41 57 41 56 45 [ 5.481880] RSP: 0018:ffffae8d8126b328 EFLAGS: 00010246 [ 5.481882] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000003 [ 5.481882] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ec790180000 [ 5.481883] RBP: ffff9ec791ee01e8 R08: ffffae8d8126b314 R09: ffffae8d8126b270 [ 5.481884] R10: 0000000000000002 R11: 343a656e696c2063 R12: ffff9ec791ee01e8 [ 5.481884] R13: ffff9ec792980000 R14: 0000000000000000 R15: ffff9ec791ee01e8 [ 5.481885] FS: 00007ff744baf8c0(0000) GS:ffff9eca9e980000(0000) knlGS:0000000000000000 [ 5.481886] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.481887] CR2: 00007ff744b9b50f CR3: 00000001100a2000 CR4: 00000000003506e0 [ 5.481888] Call Trace: [ 5.481890] dcn10_wait_for_mpcc_disconnect+0x116/0x190 [amdgpu] [ 5.482034] dcn20_plane_atomic_disable+0x3e/0x150 [amdgpu] [ 5.482178] dcn20_disable_plane+0x24/0x40 [amdgpu] [ 5.482320] dcn10_init_pipes+0x307/0x3f0 [amdgpu] [ 5.482460] dce110_enable_accelerated_mode+0x9c/0x260 [amdgpu] [ 5.482599] dc_commit_state+0x942/0xa40 [amdgpu] [ 5.482736] amdgpu_dm_atomic_commit_tail+0x585/0x2610 [amdgpu] [ 5.482878] ? kfree+0xc3/0x410 [ 5.482881] ? dcn30_validate_bandwidth+0x11f/0x270 [amdgpu] [ 5.483019] ? dcn30_validate_bandwidth+0x11f/0x270 [amdgpu] [ 5.483155] ? __bpf_trace_amdgpu_dm_plane_state_template+0x10/0x10 [amdgpu] [ 5.483295] ? dm_plane_helper_prepare_fb+0x1f1/0x250 [amdgpu] [ 5.483434] ? drm_atomic_helper_setup_commit+0x74d/0x810 [drm_kms_helper] [ 5.483446] commit_tail+0x94/0x130 [drm_kms_helper] [ 5.483457] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] [ 5.483467] drm_client_modeset_commit_atomic+0x1e4/0x220 [drm] [ 5.483488] drm_client_modeset_commit_locked+0x56/0x150 [drm] [ 5.483506] drm_client_modeset_commit+0x24/0x40 [drm] [ 5.483524] drm_fb_helper_set_par+0xa5/0xd0 [drm_kms_helper] [ 5.483533] fbcon_init+0x264/0x4f0 [ 5.483536] visual_init+0xce/0x130 [ 5.483539] do_bind_con_driver.isra.0+0x1db/0x2e0 [ 5.483541] do_take_over_console+0x116/0x180 [ 5.483542] do_fbcon_takeover+0x5c/0xc0 [ 5.483543] register_framebuffer+0x1e4/0x300 [ 5.483546] __drm_fb_helper_initial_config_and_unlock+0x321/0x4a0 [drm_kms_helper] [ 5.483556] amdgpu_fbdev_init+0xb9/0xf0 [amdgpu] [ 5.483664] amdgpu_device_init.cold+0x1625/0x1ad5 [amdgpu] [ 5.483805] ? pci_conf1_read+0xa4/0x100 [ 5.483807] ? pci_bus_read_config_word+0x49/0x70 [ 5.483810] amdgpu_driver_load_kms+0x64/0x260 [amdgpu] [ 5.483919] amdgpu_pci_probe+0x10a/0x190 [amdgpu] [ 5.484021] local_pci_probe+0x42/0x80 [ 5.484023] ? __cond_resched+0x16/0x40 [ 5.484025] pci_device_probe+0xfa/0x1b0 [ 5.484027] really_probe+0xf2/0x440 [ 5.484029] driver_probe_device+0xe1/0x150 [ 5.484031] device_driver_attach+0xa1/0xb0 [ 5.484032] __driver_attach+0x8a/0x150 [ 5.484034] ? device_driver_attach+0xb0/0xb0 [ 5.484035] ? device_driver_attach+0xb0/0xb0 [ 5.484037] bus_for_each_dev+0x78/0xc0 [ 5.484038] bus_add_driver+0x12b/0x1e0 [ 5.484040] driver_register+0x8b/0xe0 [ 5.484042] ? 0xffffffffc0f14000 [ 5.484043] do_one_initcall+0x44/0x1d0 [ 5.484045] ? do_init_module+0x23/0x260 [ 5.484047] ? kmem_cache_alloc_trace+0xfd/0x200 [ 5.484049] do_init_module+0x5c/0x260 [ 5.484050] __do_sys_finit_module+0xb1/0x110 [ 5.484052] do_syscall_64+0x33/0x80 [ 5.484054] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 5.484056] RIP: 0033:0x7ff7450689b9 [ 5.484057] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [ 5.484058] RSP: 002b:00007ffff1849268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 5.484059] RAX: ffffffffffffffda RBX: 000055a1d6cd79f0 RCX: 00007ff7450689b9 [ 5.484060] RDX: 0000000000000000 RSI: 00007ff7451f3e2d RDI: 0000000000000011 [ 5.484061] RBP: 0000000000020000 R08: 0000000000000000 R09: 000055a1d6cd4e40 [ 5.484061] R10: 0000000000000011 R11: 0000000000000246 R12: 00007ff7451f3e2d [ 5.484062] R13: 0000000000000000 R14: 000055a1d6cd7950 R15: 000055a1d6cd79f0 [ 5.484063] ---[ end trace d62e2afb8d38cfd0 ]--- -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 4

← Newer
1
...
40
41
42
43
44
45
46
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021