dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 201763] New: amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0!
by bugzilla-daemon＠bugzilla.kernel.org 19 Nov '20

19 Nov '20

https://bugzilla.kernel.org/show_bug.cgi?id=201763 Bug ID: 201763 Summary: amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0! Product: Drivers Version: 2.5 Kernel Version: 4.18.10 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: rbrito(a)ime.usp.br Regression: No Dear developers, I have a notebook that is giving me a lot of trouble, especially as it is the newest computer that I have at my disposal where I can perform any actual work. This notebook has VERY frequent lockups (hard freezes, where the screen displays something where I am working, but the keyboard does not respond, the mouse doesn't either etc.). The only way that I can resume any work is by forcibly shutting it down (by pushing the power button for many seconds) and, of course, having all previous unsaved work lost (including a previous report of this bug with the bugzilla interface). :-( There is no particular pattern that I could discover so far that triggers the problem (for the past year, at least), but I do see some error messages on my dmesg logs and I would like start with some of the more salient points by sharing some problems that I have and, perhaps, zero in on potentially loose ends that may help everybody with hardware that is similar. The notebook in question is a Dell Inspiron 5548 with a Core i7-5500U, with two graphic cards (or so I am told), with one of them being integrated with the CPU and another being a discrete AMD GPU. The userspace that I am using is a Debian testing (soon to be Debian 10) with Debian's kernel 4.18.0-2-amd64 (which is actually a kernel 4.18.10-2). I can, of course, test any other kernels for the sake of getting things fixed. Just let me know and I will do my best to fix things. BTW, no kernel that I have ever used on this machine has every worked perfectly, even the prebuilt, unpatched kernels that Ubuntu compiles daily. With that being said, when the kernel boots up, there are some red messages on the dmesg log that are related to this AMD GPU (the entire dmesg log will be attached) with some prominent lines being: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ dmesg | grep -E -i "drm|amdgpu|i965" [ 13.054583] fb: switching to inteldrmfb from EFI VGA [ 13.059874] [drm] Replacing VGA console driver [ 13.060448] [drm] ACPI BIOS requests an excessive sleep of 10000 ms, using 1500 ms instead [ 13.061122] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.061126] [drm] Driver supports precise vblank timestamp query. [ 13.067596] [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0 [ 13.071479] fbcon: inteldrmfb (fb0) is primary device [ 13.475640] [drm] amdgpu kernel modesetting enabled. [ 14.237446] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 14.238730] amdgpu 0000:04:00.0: enabling device (0100 -> 0103) [ 14.240876] [drm] initializing kernel modesetting (TOPAZ 0x1002:0x6900 0x1028:0x0643 0x00). [ 14.240888] [drm] register mmio base: 0xC2000000 [ 14.240888] [drm] register mmio size: 262144 [ 14.240898] [drm] probing gen 2 caps for device 8086:9c98 = 5323c42/0 [ 14.240899] [drm] probing mlw for device 8086:9c98 = 5323c42 [ 14.240901] [drm] add ip block number 0 <vi_common> [ 14.240901] [drm] add ip block number 1 <gmc_v7_0> [ 14.240902] [drm] add ip block number 2 <iceland_ih> [ 14.240902] [drm] add ip block number 3 <powerplay> [ 14.240903] [drm] add ip block number 4 <gfx_v8_0> [ 14.240904] [drm] add ip block number 5 <sdma_v2_4> [ 14.240905] amdgpu 0000:04:00.0: kfd not supported on this ASIC [ 14.262237] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit [ 14.346850] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_mc.bin [ 14.347897] amdgpu 0000:04:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used) [ 14.348877] amdgpu 0000:04:00.0: GTT: 256M 0x0000000000000000 - 0x000000000FFFFFFF [ 14.350661] [drm] Detected VRAM RAM=2048M, BAR=256M [ 14.351494] [drm] RAM width 64bits DDR3 [ 14.358584] [drm] amdgpu: 2048M of VRAM memory ready [ 14.359442] [drm] amdgpu: 3072M of GTT memory ready. [ 14.360290] [drm] GART: num cpu pages 65536, num gpu pages 65536 [ 14.361807] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000). [ 14.363257] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 14.364522] [drm] Driver supports precise vblank timestamp query. [ 14.365629] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_pfp.bin [ 14.366113] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_me.bin [ 14.366262] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_ce.bin [ 14.366264] [drm] Chained IB support enabled! [ 14.366414] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_rlc.bin [ 14.381603] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_mec.bin [ 14.384759] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_sdma.bin [ 14.386476] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_sdma1.bin [ 14.461717] amdgpu 0000:04:00.0: firmware: direct-loading firmware amdgpu/topaz_smc.bin [ 14.465233] amdgpu: [powerplay] can't get the mac of 5 [ 14.467411] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0! [ 14.477284] [drm] Initialized amdgpu 3.26.0 20150101 for 0000:04:00.0 on minor 1 [ 21.824595] amdgpu: [powerplay] VI should always have 2 performance levels [ 21.871775] amdgpu 0000:04:00.0: GPU pci config reset [ 22.574755] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000). [ 22.577374] amdgpu: [powerplay] can't get the mac of 5 [ 22.578782] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0! [ 29.802702] amdgpu: [powerplay] VI should always have 2 performance levels [ 29.848230] amdgpu 0000:04:00.0: GPU pci config reset - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Well, that's it. Please let me know whatever information you want me to get and I will post it here. Reiterating: I can compile kernels and or run other programs to diagnose anything that you want me to to fix these issues. Thanks in advance, Rogério Brito. -- You are receiving this mail because: You are watching the assignee of the bug.

1 13

[Bug 203339] New: AMDGPU: virtual_display disables physical outputs
by bugzilla-daemon＠bugzilla.kernel.org 21 Oct '20

21 Oct '20

https://bugzilla.kernel.org/show_bug.cgi?id=203339 Bug ID: 203339 Summary: AMDGPU: virtual_display disables physical outputs Product: Drivers Version: 2.5 Kernel Version: 5.0.7 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: parker.l.reed(a)gmail.com Regression: No Created attachment 282351 --> https://bugzilla.kernel.org/attachment.cgi?id=282351&action=edit Kernel log Unable to tell if this is intended or if caused by a crash. I have a monitor connected via HDMI. When I use the virtual_display kernel parameter, only the virtual displays show up. amdgpu.virtual_display=0000:07:00.0,2 Original patchset doesn't mention this usecase. https://lists.freedesktop.org/archives/amd-gfx/2016-August/001058.html Kernel log attached shows some crashes related to dce_virtual_crtc -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 203471] New: Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
by bugzilla-daemon＠bugzilla.kernel.org 16 Oct '20

16 Oct '20

https://bugzilla.kernel.org/show_bug.cgi?id=203471 Bug ID: 203471 Summary: Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled Product: Drivers Version: 2.5 Kernel Version: 5.1 rc6 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: haxk612(a)gmail.com Regression: No I have Acer Nitro 5 AN515-42 with Ryzen 5 2500U and RX560X. When i launch some game with DRI_PRIME=1 to have it on dGPU there is huge tearing on top of the screen that is there with or without Vsync. If i launch the game on iGPU there is no tearing at all. Also the tearing happens only when the game is in fullscreen. If i take a screenshot there is no tearing in the screenshot. And i cannot post a picture as my phone camera is broken in my latest build of android. I have tried 5.2-wip branch and there is the same issue. Will post dmesg and journalctl in few hours. -- You are receiving this mail because: You are watching the assignee of the bug.

1 26

[Bug 199979] New: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control
by bugzilla-daemon＠bugzilla.kernel.org 06 Oct '20

06 Oct '20

https://bugzilla.kernel.org/show_bug.cgi?id=199979 Bug ID: 199979 Summary: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control Product: Drivers Version: 2.5 Kernel Version: 4.17.0 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: CWidmer(a)umbrox.de Regression: No When using the hardware monitoring interface to change pwm1_enable to 2 (automatic) from 1 (manual), the automatic fan control does not work as expected. Instead, the pwm1 value keeps jumping around between at least two values and a continuous, persisting, and unpleasantly high-pitched sound can be heard from inside the computer case. The only way to stop those things is writing some valid value to pwm1, which in turn also switches pwm1_enable back to 1. If the system is booted without ever manually changing the pwm1_enable value, which then defaults to 2, automatic fan control does work as intended. I am using a custom RX 580 (Sapphire Nitro+ Radeon RX 580 8GD5 Special Edition) on a Gentoo x86_64 system and was able to reproduce the issue with the 4.17.0 kernel with Gentoo patches, the Ubuntu kernel on the 18.04 image (should be a 4.15 one) and also with amd-staging-drm-next. -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[Bug 198551] New: amdgpu error on shutdown or gpu intense game
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '20

24 Sep '20

https://bugzilla.kernel.org/show_bug.cgi?id=198551 Bug ID: 198551 Summary: amdgpu error on shutdown or gpu intense game Product: Drivers Version: 2.5 Kernel Version: 4.14.14-1 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: illuslion1998(a)gmail.com Regression: No Created attachment 273797 --> https://bugzilla.kernel.org/attachment.cgi?id=273797&action=edit amdgpu error log I get this error sometimes when I try to shutdown my computer. It freezes everything and I have to hard reset my computer. This sometimes also happens when I play a GPU intense game. (Example CS:GO). My GPU is Radeon R5 M255. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
by Daniel Vetter 23 Sep '20

23 Sep '20

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d5cefb1cb2a2..058512f14772 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -2018,15 +2018,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.18.0

3 11

[PATCH 0/7] drm/omap: misc improvements
by Tomi Valkeinen 22 Sep '20

22 Sep '20

Hi, Misc improvements to omapdrm which have been lying around for a long time, and I've missed upstreaming them. And one new one, which makes the DSS5 HDMI pick up the color range automatically. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (3): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes drm/omap: dss: platform_register_drivers() to dss.c and remove core.c Tomi Valkeinen (3): drm/omap: drop unneeded locking from mgr_fld_write() drm/omap: fix missing scaler pixel fmt limitations drm/omap: hdmi5: automatically choose limited/full range output drivers/gpu/drm/omapdrm/dss/Makefile | 2 +- drivers/gpu/drm/omapdrm/dss/core.c | 55 -------- drivers/gpu/drm/omapdrm/dss/dispc.c | 160 +++++++++++++++++------ drivers/gpu/drm/omapdrm/dss/dss.c | 37 ++++++ drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 125 ++++++++++-------- drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 + drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++++- drivers/gpu/drm/omapdrm/omap_plane.c | 30 +++++ 8 files changed, 295 insertions(+), 157 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 33

[Bug 203033] New: nouveau hung task
by bugzilla-daemon＠bugzilla.kernel.org 28 Aug '20

28 Aug '20

https://bugzilla.kernel.org/show_bug.cgi?id=203033 Bug ID: 203033 Summary: nouveau hung task Product: Drivers Version: 2.5 Kernel Version: 5.0.0 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: mcroce(a)redhat.com Regression: No The GUI freezes randomly with nouveau with this error in the syslog: INFO: task kworker/u16:4:14755 blocked for more than 120 seconds. Not tainted 5.0.0-matteo #28 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:4 D 0 14755 2 0x80000000 Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau] Call Trace: ? __schedule+0x1a6/0x6c0 schedule+0x2c/0x70 schedule_timeout+0x268/0x380 ? nvif_notify_get+0x94/0xa0 [nouveau] dma_fence_default_wait+0x204/0x270 ? dma_fence_release+0x90/0x90 dma_fence_wait_timeout+0xdd/0x100 drm_atomic_helper_wait_for_fences+0x3a/0xc0 [drm_kms_helper] nv50_disp_atomic_commit_tail+0x7c/0x850 [nouveau] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x40/0x70 process_one_work+0x1fa/0x400 worker_thread+0x2d/0x3d0 ? process_one_work+0x400/0x400 kthread+0x113/0x130 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x35/0x40 -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 204609] New: amdgpu: powerplay failed send message
by bugzilla-daemon＠bugzilla.kernel.org 15 Aug '20

15 Aug '20

https://bugzilla.kernel.org/show_bug.cgi?id=204609 Bug ID: 204609 Summary: amdgpu: powerplay failed send message Product: Drivers Version: 2.5 Kernel Version: 5.3.0-rc3-drm-next 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: kingoipo(a)gmail.com Regression: No Created attachment 284483 --> https://bugzilla.kernel.org/attachment.cgi?id=284483&action=edit dmesg Always when booting and sometimes during regular usage, the following messages appear: > amdgpu: [powerplay] failed send message: TransferTableSmu2Dram (18) param: > 0x00000006 response 0xffffffc2 > amdgpu: [powerplay] failed send message: NumOfDisplays (64) param: > 0x00000002 response 0xffffffc2 My hardware is a Sapphire RX 5700 on an x570 motherboard. The kernel is build from https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next commit 283791cbb202ae73002de4a6c53f835e4406b276. Mesa is from oibaf's ppa for ubuntu 19.04: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers?field.series_… Xorg is distro provided 1.20.4 with amdgpu driver version 19.0.1 -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[RFC v2 00/11] DVFS in the OPP core
by Rajendra Nayak 12 Aug '20

12 Aug '20

This is a v2 of the RFC posted earlier by Stephen Boyd [1] As part of v2 I still follow the same approach of dev_pm_opp_set_rate() API using clk framework to round the frequency passed and making it accept 0 as a valid frequency indicating the frequency isn't required anymore. It just has a few more drivers converted to use this approach like dsi/dpu and ufs. ufs demonstrates the case of having to handle multiple power domains, one of which is scalable. The patches are based on 5.1-rc1 and depend on some ufs fixes I posted earlier [2] and a DT patch to include the rpmpd header [3] [1] https://lkml.org/lkml/2019/1/28/2086 [2] https://lkml.org/lkml/2019/3/8/70 [3] https://lkml.org/lkml/2019/3/20/120 Rajendra Nayak (10): OPP: Make dev_pm_opp_set_rate() with freq=0 as valid tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state spi: spi-geni-qcom: Use OPP API to set clk/perf state arm64: dts: sdm845: Add OPP table for all qup devices scsi: ufs: Add support to manage multiple power domains in ufshcd-pltfrm scsi: ufs: Add support for specifying OPP tables in DT arm64: dts: sdm845: Add ufs opps and power-domains drm/msm/dpu: Use OPP API to set clk/perf state drm/msm: dsi: Use OPP API to set clk/perf state arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains Stephen Boyd (1): OPP: Don't overwrite rounded clk rate arch/arm64/boot/dts/qcom/sdm845.dtsi | 194 +++++++++++++++++- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 7 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 + drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 88 +++++++- drivers/opp/core.c | 26 ++- drivers/scsi/ufs/ufshcd-pltfrm.c | 52 ++++- drivers/scsi/ufs/ufshcd.c | 21 +- drivers/scsi/ufs/ufshcd.h | 3 + drivers/spi/spi-geni-qcom.c | 14 +- drivers/tty/serial/qcom_geni_serial.c | 15 +- 12 files changed, 406 insertions(+), 29 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 35

← Newer
1
2
3
4
5
6
7
...
228
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019