dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[Bug 214425] New: [drm][amdgpu][TTM] Page pool memory never gets freed
by bugzilla-daemon＠bugzilla.kernel.org 15 Sep '21

15 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=214425 Bug ID: 214425 Summary: [drm][amdgpu][TTM] Page pool memory never gets freed Product: Drivers Version: 2.5 Kernel Version: 5.14.3 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: doucha(a)swarmtech.cz Regression: No Hello, while playing certain webGL games, I've noticed what appears to be a memory leak in the kernel. Further investigation revealed that after about an hour of gameplay, over 3GB of memory (half of all available RAM on my machine) will be taken by the TTM page pool. While the excessive allocation may be caused by a resource leak in the game itself (I need to investigate that further), the larger problem is that TTM never releases the memory even after I quit the game. Closing the game only moves the allocated memory from active buffer objects to idle memory pool where it'll get stuck until I reboot the system. Shutting down X server doesn't release the memory either. System specs: HP Probook 455 G7 AMD Ryzen 5 4500U CPU AMD Renoir GPU (Mesa 21.2.1, LLVM 12.0) Gentoo Linux TTM statistics before quitting the game: /sys/kernel/debug/ttm/buffer_objects: 3116 /sys/kernel/debug/ttm/page_pool: --- 0--- --- 1--- --- 2--- --- 3--- --- 4--- --- 5--- --- 6--- --- 7--- --- 8--- --- 9--- ---10--- wc : 2 2 1 1 8 2 0 1 2 1 2 uc : 0 0 0 0 0 0 0 0 0 0 0 wc 32 : 0 0 0 0 0 0 0 0 0 0 0 uc 32 : 0 0 0 0 0 0 0 0 0 0 0 total : 3410 of 939433 /sys/kernel/debug/ttm/page_pool_shrink: 2898/512 ======================================= TTM statistics after quitting the game (until reboot): /sys/kernel/debug/ttm/buffer_objects: 403 /sys/kernel/debug/ttm/page_pool: --- 0--- --- 1--- --- 2--- --- 3--- --- 4--- --- 5--- --- 6--- --- 7--- --- 8--- --- 9--- ---10--- wc : 151 134 20 5 255 241 790 193 416 1121 83 uc : 0 0 0 0 0 0 0 0 0 0 0 wc 32 : 0 0 0 0 0 0 0 0 0 0 0 uc 32 : 0 0 0 0 0 0 0 0 0 0 0 total : 853035 of 939433 /sys/kernel/debug/ttm/page_pool_shrink: 853034/1 -- 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 0

[PATCH] drm/v3d: fix wait for TMU write combiner flush
by Iago Toral Quiroga 15 Sep '21

15 Sep '21

The hardware sets the TMUWCF bit back to 0 when the TMU write combiner flush completes so we should be checking for that instead of the L2TFLS bit. Fixes spurious Vulkan CTS failures in: dEQP-VK.binding_model.descriptorset_random.* --- drivers/gpu/drm/v3d/v3d_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index a3529809d547..5159f544bc16 100644 --- a/drivers/gpu/drm/v3d/v3d_gem.c +++ b/drivers/gpu/drm/v3d/v3d_gem.c @@ -197,7 +197,7 @@ v3d_clean_caches(struct v3d_dev *v3d) V3D_CORE_WRITE(core, V3D_CTL_L2TCACTL, V3D_L2TCACTL_TMUWCF); if (wait_for(!(V3D_CORE_READ(core, V3D_CTL_L2TCACTL) & - V3D_L2TCACTL_L2TFLS), 100)) { + V3D_L2TCACTL_TMUWCF), 100)) { DRM_ERROR("Timeout waiting for L1T write combiner flush\n"); } -- 2.25.1

4 4

[PATCH RESEND v2 0/3] lib, stackdepot: check stackdepot handle before accessing slabs
by Imran Khan 15 Sep '21

15 Sep '21

Changes in v2: - Fixed compilation error [1] due to typo in patch-3 (stack_depot_print used in place of stack_depot_snprint) This compilation error appears with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y and this was missed by my test config (x86_64_defconfig) [1] https://patchwork.freedesktop.org/series/94696/ Original cover letter ------------------------------------------ This patch series consolidates the changes submitted and reviewed at [1] and [2]. The patches at [1] and [2] were submitted separarely, but they have some inter dependency (later patches were created on top of earlier ones). As both sets are still under review, I have put them in a single change set here, so that it can be reviewed/included together and also to avoid automation build failures where git am fails because of absent parent. I have included Acked-by (from Vlastimil) and Reviewed-by (from Alexander) tags obtained so far for these changes and have also addressed last review comment from Vlastimil [3]. To summarize, the changes in this set are as follows: PATCH-1: Checks validity of a stackdepot handle before proceeding to access stackdepot slab/objects. PATCH-2: Adds a helper in stackdepot, to allow users to print stack entries just by specifying the stackdepot handle. It also changes such users to use this new interface. PATCH-3: Adds a helper in stackdepot, to allow users to print stack entries into buffers just by specifying the stackdepot handle and destination buffer. It also changes such users to use this new interface. [1] https://lore.kernel.org/lkml/20210902000154.1096484-1-imran.f.khan@oracle.c… [2] https://lore.kernel.org/lkml/20210910141001.1622130-1-imran.f.khan@oracle.c… [3] https://lore.kernel.org/lkml/ef0aa660-0cb6-dc21-f2ce-368b34f8af3d@suse.cz/ Imran Khan (3): lib, stackdepot: check stackdepot handle before accessing slabs. lib, stackdepot: Add helper to print stack entries. lib, stackdepot: Add helper to print stack entries into buffer. drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-- drivers/gpu/drm/drm_mm.c | 5 +-- drivers/gpu/drm/i915/i915_vma.c | 5 +-- drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +++-------- include/linux/stackdepot.h | 5 +++ lib/stackdepot.c | 45 +++++++++++++++++++++++++ mm/kasan/report.c | 15 ++------- mm/page_owner.c | 18 +++------- 8 files changed, 66 insertions(+), 52 deletions(-) -- 2.30.2

1 3

[PATCH] drm/radeon: make array encoded_lanes static
by Colin King 15 Sep '21

15 Sep '21

From: Colin Ian King <colin.king(a)canonical.com> Don't populate the read-only array encoded_lanes on the stack but instead it static. Also makes the object code smaller by 97 bytes: Before: text data bss dec hex filename 38899 8064 0 46963 b773 ./drivers/gpu/drm/radeon/r600_dpm.o After: text data bss dec hex filename 38738 8128 0 46866 b712 ./drivers/gpu/drm/radeon/r600_dpm.o (gcc version 11.2.0) Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/radeon/r600_dpm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600_dpm.c b/drivers/gpu/drm/radeon/r600_dpm.c index fd4226b99862..9d2bcb9551e6 100644 --- a/drivers/gpu/drm/radeon/r600_dpm.c +++ b/drivers/gpu/drm/radeon/r600_dpm.c @@ -1361,7 +1361,9 @@ u16 r600_get_pcie_lane_support(struct radeon_device *rdev, u8 r600_encode_pci_lane_width(u32 lanes) { - u8 encoded_lanes[] = { 0, 1, 2, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0, 6 }; + static const u8 encoded_lanes[] = { + 0, 1, 2, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0, 6 + }; if (lanes > 16) return 0; -- 2.32.0

2 1

[PATCH 1/2] drm/sched: fix the bug of time out calculation(v4)
by Monk Liu 15 Sep '21

15 Sep '21

issue: in cleanup_job the cancle_delayed_work will cancel a TO timer even the its corresponding job is still running. fix: do not cancel the timer in cleanup_job, instead do the cancelling only when the heading job is signaled, and if there is a "next" job we start_timeout again. v2: further cleanup the logic, and do the TDR timer cancelling if the signaled job is the last one in its scheduler. v3: change the issue description remove the cancel_delayed_work in the begining of the cleanup_job recover the implement of drm_sched_job_begin. v4: remove the kthread_should_park() checking in cleanup_job routine, we should cleanup the signaled job asap TODO: 1)introduce pause/resume scheduler in job_timeout to serial the handling of scheduler and job_timeout. 2)drop the bad job's del and insert in scheduler due to above serialization (no race issue anymore with the serialization) tested-by: jingwen <jingwen.chen@@amd.com> Signed-off-by: Monk Liu <Monk.Liu(a)amd.com> --- drivers/gpu/drm/scheduler/sched_main.c | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index a2a9536..3e0bbc7 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -676,15 +676,6 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) { struct drm_sched_job *job, *next; - /* - * Don't destroy jobs while the timeout worker is running OR thread - * is being parked and hence assumed to not touch pending_list - */ - if ((sched->timeout != MAX_SCHEDULE_TIMEOUT && - !cancel_delayed_work(&sched->work_tdr)) || - kthread_should_park()) - return NULL; - spin_lock(&sched->job_list_lock); job = list_first_entry_or_null(&sched->pending_list, @@ -693,17 +684,21 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) if (job && dma_fence_is_signaled(&job->s_fence->finished)) { /* remove job from pending_list */ list_del_init(&job->list); + + /* cancel this job's TO timer */ + cancel_delayed_work(&sched->work_tdr); /* make the scheduled timestamp more accurate */ next = list_first_entry_or_null(&sched->pending_list, typeof(*next), list); - if (next) + + if (next) { next->s_fence->scheduled.timestamp = job->s_fence->finished.timestamp; - + /* start TO timer for next job */ + drm_sched_start_timeout(sched); + } } else { job = NULL; - /* queue timeout for next job */ - drm_sched_start_timeout(sched); } spin_unlock(&sched->job_list_lock); @@ -791,11 +786,8 @@ static int drm_sched_main(void *param) (entity = drm_sched_select_entity(sched))) || kthread_should_stop()); - if (cleanup_job) { + if (cleanup_job) sched->ops->free_job(cleanup_job); - /* queue timeout for next job */ - drm_sched_start_timeout(sched); - } if (!entity) continue; -- 2.7.4

5 7

[PATCH] drm: Fix scaling_mode docs
by Ville Syrjala 15 Sep '21

15 Sep '21

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fix the bad copy-pasta in the scaling_mode docs. Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_connector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index e0a30e0ee86a..3bc782b630b9 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1620,7 +1620,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_properties); * connectors. * * Atomic drivers should use drm_connector_attach_scaling_mode_property() - * instead to correctly assign &drm_connector_state.picture_aspect_ratio + * instead to correctly assign &drm_connector_state.scaling_mode * in the atomic state. */ int drm_mode_create_scaling_mode_property(struct drm_device *dev) @@ -1740,7 +1740,7 @@ EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property); * @scaling_mode_mask: or'ed mask of BIT(%DRM_MODE_SCALE_\*). * * This is used to add support for scaling mode to atomic drivers. - * The scaling mode will be set to &drm_connector_state.picture_aspect_ratio + * The scaling mode will be set to &drm_connector_state.scaling_mode * and can be used from &drm_connector_helper_funcs->atomic_check for validation. * * This is the atomic version of drm_mode_create_scaling_mode_property(). -- 2.32.0

2 1

[PATCH] drm/i915: Add mmap lock around vma_lookup() to prevent lockdep splats
by Maarten Lankhorst 15 Sep '21

15 Sep '21

Fixes the following splat: i915: Running i915_gem_mman_live_selftests/igt_mmap ------------[ cut here ]------------ WARNING: CPU: 3 PID: 5654 at include/linux/mmap_lock.h:164 find_vma+0x4e/0xb0 Modules linked in: i915(+) vgem fuse snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm ttm mei_me pps_core i2c_i801 prime_numbers i2c_smbus mei [last unloaded: i915] CPU: 3 PID: 5654 Comm: i915_selftest Tainted: G U 5.15.0-rc1-CI-Trybot_7984+ #1 Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.00 10/31/2017 RIP: 0010:find_vma+0x4e/0xb0 Code: de 48 89 ef e8 d3 94 fe ff 48 85 c0 74 34 48 83 c4 08 5b 5d c3 48 8d bf 28 01 00 00 be ff ff ff ff e8 d6 46 8b 00 85 c0 75 c8 <0f> 0b 48 8b 85 b8 00 00 00 48 85 c0 75 c6 48 89 ef e8 12 26 87 00 RSP: 0018:ffffc900013df980 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00007f9df2b80000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff822e314c RDI: ffffffff8233c83f RBP: ffff88811bafc840 R08: ffff888107d0ddb8 R09: 00000000fffffffe R10: 0000000000000001 R11: 00000000ffbae7ba R12: 0000000000000000 R13: 0000000000000000 R14: ffff88812a710000 R15: ffff888114fa42c0 FS: 00007f9def9d4c00(0000) GS:ffff888266580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f799627fe50 CR3: 000000011bbc2006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __igt_mmap+0xe0/0x490 [i915] igt_mmap+0xd2/0x160 [i915] ? __trace_bprintk+0x6e/0x80 __i915_subtests.cold.7+0x42/0x92 [i915] ? i915_perf_selftests+0x20/0x20 [i915] ? __i915_nop_setup+0x10/0x10 [i915] __run_selftests.part.3+0x10d/0x172 [i915] i915_live_selftests.cold.5+0x1f/0x47 [i915] i915_pci_probe+0x93/0x1d0 [i915] Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/4129 --- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index 02d40eb31a4c..e69e8861352d 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -907,7 +907,9 @@ static int __igt_mmap(struct drm_i915_private *i915, pr_debug("igt_mmap(%s, %d) @ %lx\n", obj->mm.region->name, type, addr); + mmap_read_lock(current->mm); area = vma_lookup(current->mm, addr); + mmap_read_unlock(current->mm); if (!area) { pr_err("%s: Did not create a vm_area_struct for the mmap\n", obj->mm.region->name); -- 2.33.0

2 2

Intel UHD resolutions
by Randy Dunlap 15 Sep '21

15 Sep '21

Hi, I would like to use QHD resolution (2560x1440) with my shiny new computer and display. That resolution works if I boot Windows 10 (cough). What do I need to do to use that resolution in Linux? I first tried openSUSE 15.3 (kernel 5.3.18-59.19-default) then I build a v5.14 kernel and tried that. Both of them max out at FHD (1920x1080). I am booting with "i915.force_probe=4c8a" on the kernel command line. My desktop is XFCE4. CPU is: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 167 model name : 11th Gen Intel(R) Core(TM) i9-11900 @ 2.50GHz stepping : 1 microcode : 0x40 cpu MHz : 1021.742 cache size : 16384 KB physical id : 0 siblings : 16 with an H470 chipset. (ASRock DeskMini H470) 00:02.0 VGA compatible controller: Intel Corporation RocketLake-S GT1 [UHD Graphics 750] (rev 04) or verbose: 00:02.0 VGA compatible controller: Intel Corporation RocketLake-S GT1 [UHD Graphics 750] (rev 04) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 4c8a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 153 Region 0: Memory at b0000000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at a0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 3000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, O BFF Not Supported AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled AtomicOpsCtl: ReqEn- Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit- Address: fee00018 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot -,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 14 PASIDCtl: Enable- Exec- Priv- Capabilities: [200 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [300 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00008000, Page Request Allocation: 00000000 Kernel driver in use: i915 Kernel modules: i915 thanks. -- ~Randy

3 3

Deploying new iterator interface for dma-buf
by Christian König 15 Sep '21

15 Sep '21

Hi everybody, we recently found that a good bunch of the RCU accesses to the dma_resv object are actually not correctly protected. Those where fixed by either dropping the RCU approach and taking appropriate locks or using a central function to return the current fences as array and then work with that snapshot. This set now tries to prevent adding any new broken code by rolling out two new interfaces to access the fences in a dma_resv object: dma_resv_for_each_fence() - Iterator which should be used while holding the reservation lock. dma_resv_for_each_fence_unlocked() - Iterator based on RCU which can be used without holding the reservation lock and automatic restart on concurrent modification. While doing this we also move the decision which fences to use for write and read accesses into the dma_resv object which results in a quite nice code de-duplication and simplification. The only two remaining users of the RCU shared fence interface are removing shared fences in amdkfd and debugfs code in qxl which will both be addresses in the next patch set. Please review and/or comment, Christian.

2 39

[PATCH 0/1] lib, stackdepot: Add helper to print stack entries into buffer.
by Imran Khan 15 Sep '21

15 Sep '21

This change is in response to discussion at [1]. The patch has been created on top of my earlier changes [2] and [3]. If needed I can resend all of these patches together, though my earlier patches have been Acked. [1] https://lore.kernel.org/lkml/e6f6fb85-1d83-425b-9e36-b5784cc9e69a@suse.cz/ [2] https://lore.kernel.org/lkml/fe94ffd8-d235-87d8-9c3d-80f7f73e0c4e@suse.cz/ [3] https://lore.kernel.org/lkml/85f4f073-0b5a-9052-0ba9-74d450608656@suse.cz/ Imran Khan (1): lib, stackdepot: Add helper to print stack entries into buffer. drivers/gpu/drm/drm_dp_mst_topology.c | 5 +---- drivers/gpu/drm/drm_mm.c | 5 +---- drivers/gpu/drm/i915/i915_vma.c | 5 +---- drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +++++--------------- include/linux/stackdepot.h | 3 +++ lib/stackdepot.c | 23 +++++++++++++++++++++++ mm/page_owner.c | 5 +---- 7 files changed, 35 insertions(+), 31 deletions(-) -- 2.30.2

4 6

← Newer
1
...
54
55
56
57
58
59
60
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021