dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 201957] New: amdgpu: ring gfx timeout
by bugzilla-daemon＠bugzilla.kernel.org 23 Jun '22

23 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=201957 Bug ID: 201957 Summary: amdgpu: ring gfx timeout Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20-rc5 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: felix.adrianto(a)gmail.com Regression: No Error message: [Dec 5 22:08] amdgpu 0000:23:00.0: GPU fault detected: 146 0x0000480c for process yuzu pid 2920 thread yuzu:cs0 pid 2935 [ +0.000005] amdgpu 0000:23:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ +0.000002] amdgpu 0000:23:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0604800C [ +0.000003] amdgpu 0000:23:00.0: VM fault (0x0c, vmid 3, pasid 32770) at page 0, read from 'TC4' (0x54433400) (72) [ +10.053011] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=37241, emitted seq=37244 [ +0.000007] [drm] GPU recovery disabled. How to reproduce the issue: 1. Playing with yuzu-emulator 2. Load Super Mario Odyssey 3. Start new game 4. When Mario is about to jump for the first time after being woken up by Cappy, this bug must occur. During the issue, the following occured: 1. Graphic locked up. 2. System can be access through SSH. System specification: Debian Sid Radeon RX 580 I have tried the following combination: 1. Kernel 4.17, 4.18, 4.19, 4.20, drm-next-4.21.wip 2. Mesa 18.2, 18.3, 19.0-development branch But none of the above combination fixes the issue. Let me know if you need more information and more testing from me. -- You are receiving this mail because: You are watching the assignee of the bug.

2 79

[Bug 172421] New: radeon: allow to set the TMDS frequency by a special kernel parameter
by bugzilla-daemon＠bugzilla.kernel.org 19 Jun '22

19 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=172421 Bug ID: 172421 Summary: radeon: allow to set the TMDS frequency by a special kernel parameter Product: Drivers Version: 2.5 Kernel Version: 4.8.0-rc7+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: estellnb(a)elstel.org Regression: No Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The only prove I have for this is a comercial invoice from Nexus Mobile and a packaging card. As far as I know Radeon R5 230 cards currently sold can still be run stable and reliable under UltraHD provided that you apply the right kernel patch (see for the attachement). Unfortunately neither my former merchant nor ATI have responded about my questions concerning this change in trade and marketing policy. My request would now be to integrate the provided patch into the mainline kernel. It does not change the behaviour of the radeon driver unless you specify a nonzero value for the radeon.hdmimhz parameter. If you do I have tested the R5 230 cards I have to run stable and reliably for days. At least the 2GB variant of this card has largely sufficient resources for proficient desktop computing under UltraHD including image manipulation in 3840x2160. While never officially discussed for the radeon driver nouveau is already implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x. Though it thereby becomes possible to specify a hdmimhz that is far above the cards technical possibilties the nouveau developers I have talked with say that it would rarely be possible to damage any card by overcloking the TMDS. In deed I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p. Even specifying values considerable higher than 225MHz did not damage my GeForce 9600M GT though the screen stayed black upon the nouveau driver initialization. While the Radeon R5 230 works well at 297MHz (as long as you specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz like 330 though the HDMI input of my monitor features no more than 30Hz at 3840x2160 (tested with or without a DP-adapter). While it remains questionable if the provided patch can improve things for newer Radeon cards I would believe it to be beneficial for some elder cards. At least it is known to be beneficial for the R5 230 initially marketed as 4K-ready. The according radeon patch provided with this report has so far already been accepted by the Mageia 6 distribution. Though the attached patch is for application at the current 4.8.0-rcX+ kernels most of my machines that rely on it still run with 4.6.0. -- You are receiving this mail because: You are watching the assignee of the bug.

2 23

[Bug 201497] New: [amdgpu]: '*ERROR* No EDID read' is back in 4.19
by bugzilla-daemon＠bugzilla.kernel.org 19 May '22

19 May '22

https://bugzilla.kernel.org/show_bug.cgi?id=201497 Bug ID: 201497 Summary: [amdgpu]: '*ERROR* No EDID read' is back in 4.19 Product: Drivers Version: 2.5 Kernel Version: 4.19 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: engywook(a)gmail.com Regression: No Hey, I have this EDID bug again, see https://lists.freedesktop.org/archives/amd-gfx/2018-July/023923.html 018d82e5f02ef3583411bcaa4e00c69786f46f19 seems to have gotten back in through: # first bad commit: [d98c71dadc2d0debdb80beb5a478baf1e6f98758] Merge drm-upstream/drm-next into drm-misc-next / Daniel -- You are receiving this mail because: You are watching the assignee of the bug.

2 26

[Bug 201991] New: amdgpu: clock management is disabled for the 4K resolution with polaris 10
by bugzilla-daemon＠bugzilla.kernel.org 29 Apr '22

29 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=201991 Bug ID: 201991 Summary: amdgpu: clock management is disabled for the 4K resolution with polaris 10 Product: Drivers Version: 2.5 Kernel Version: 4.18.0,4.20.0-rc6, drm-next-4.21-wip Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: fin4478(a)hotmail.com Regression: No Created attachment 280019 --> https://bugzilla.kernel.org/attachment.cgi?id=280019&action=edit simple app for the amdgpu sys interface When the Xfce desktop is visible at 4K and idling, the engine clock is fixed at level 6: 1220MHz and you can not change that. The temperature is 38 C. When the monitor is sleeping, then the engine clock is 300Mhz. The automatic power management works with 2560x1600 and lower resolutions as espected. I tested with my python app and I have latest drivers, including firmware files. My monitor is ASUS VP28UQG and I use the display port. System: Host: ryzenpc Kernel: 4.20.0-rc6 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux buster/sid Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x serial: <root required> UEFI [Legacy]: American Megatrends v: 4023 date: 08/20/2018 CPU: 6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2851 MHz Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.20.0-rc6 LLVM 7.0.1) v: 4.5 Mesa 19.0.0-devel (git-9ebc00f 2018-12-13 bionic-oibaf-ppa) -- You are receiving this mail because: You are watching the assignee of the bug.

2 6

[RFC 00/21] Renesas r8a7795/Salvator-X HDMI output prototype
by Ulrich Hecht 26 Apr '22

26 Apr '22

Hi! This is a prototype of HDMI output support for the Renesas r8a7795 SoC and Salvator-X board. It is based on the renesas-devel-20160516-v4.6 tree and includes the bridge API conversion patches to the adv7511 and rcar-du drivers written by Archit Taneja. The obvious issue with this series is the awkward binding of the dw-hdmi bridge IP, which can be seen in the "drm: rcar-du: Add dw_hdmi driver startup" patch. Any comments on how to implement this interface properly are much appreciated. Functionally, this series works as expected on both connectors, but EDID reading is currently broken. CU Uli Archit Taneja (2): drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder drm: i2c: adv7511: Convert to drm_bridge Koji Matsuoka (12): media: vsp1: Set format to RPF input source drm: bridge/dw_hdmi: Fix R-Car Gen3 device support drm: rcar-du: Add R8A7795 device support drm: rcar-du: Add dw_hdmi driver startup drm: rcar-du: Add DPLL support drm: rcar-du: Fix display registers for R-Car Gen3 drm: rcar-du: Fix VSP plane number per devices drm: rcar-du: Fix VSP feed plane number drm: rcar-du: Add pixel format support drm: rcar-du: Fix display max size to 4096x2160 size arm64: dts: salvator-x: Add DU pins, HDMI connectors and encoder arm64: configs: Enable R-Car DU related config Kuninori Morimoto (1): arm64: defconfig: add VIDEO_RENESAS_FCP Ulrich Hecht (5): v4l: vsp1: Change VSP1 LIF linebuffer FIFO pinctrl: sh-pfc: r8a7795: Add DU support pinctrl: sh-pfc: r8a7795: Add HDMI CEC support arm64: dts: r8a7795: Add HDMI encoder support arm64: dts: r8a7795: add HDMI support to DU Vladimir Zapolskiy (1): drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 107 +++++ arch/arm64/boot/dts/renesas/r8a7795.dtsi | 33 +- arch/arm64/configs/defconfig | 15 + drivers/gpu/drm/bridge/dw-hdmi.c | 489 +++++++++++++++++++-- drivers/gpu/drm/i2c/adv7511.c | 224 ++++++---- drivers/gpu/drm/rcar-du/Kconfig | 2 + drivers/gpu/drm/rcar-du/Makefile | 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 97 +++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 12 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 20 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 13 +- drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 + drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 117 ----- drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 -- drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 260 ++++++++--- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 68 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_plane.c | 8 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 7 +- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 19 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 51 ++- drivers/media/platform/vsp1/vsp1_drm.c | 6 + drivers/media/platform/vsp1/vsp1_lif.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 113 +++++ include/drm/bridge/dw_hdmi.h | 9 + 27 files changed, 1388 insertions(+), 346 deletions(-) delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h -- 2.7.4

6 28

[PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433
by Andrzej Hajda 03 Mar '22

03 Mar '22

Hi Inki, GSCALERs in Exynos SoCs support conversion between wide range of image formats, plus scaling and rotation. Driver already supports mem2mem mode - via ExynosDRM IPP framework. This patchset adds support for mem to display mode - framebuffers can be converted, scaled and send directly to Display Controller. From DRM framework's point of view every GSCALER exposes drm_plane which can be connected to display controller (display panel or TV). The feature is not well documented so the development was quite difficult - a process of trial and error, vendor code analysis, guessing from datasheets. Hopefully most of the issues were solved. I have developed and tested it on TM2 device with panel and TV paths. The patchset contains three parts: 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and drm_plane related structures, to allow usage of planes which are not physically bound to crtcs (01-13). 2. Adding local path support to GSCALER and DECON (14-20). 3. Few fixes of bugs existing already in the code but discovered due to added local path support (21-23). The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it is required to allow set z-pos position of GSCALER planes. To simplify tests I have also created branch containing all required patches: Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos Branch: sandbox/ahajda/dev/exynos-drm-local-path This is v2 version of the patchset. In this version I have moved code setting cursor plane in crtc to separate patch together with code disabling fast cursor updates - hardware does not support it. To keep bisectability DTS patches should be applied before subsequent ones. It is rebased on today's exynos-drm-next. Please be aware that DTS patches has been already applied to samsung-soc tree, I left them here to simplify testing on exynos-drm-next, which is not in sync with samsung-soc, for this reason I have moved them on the beginning of the patchset. Regards Andrzej Andrzej Hajda (24): arm64: dts: exynos: configure GSCALER related clocks arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs drm/exynos: remove exynos_drm_plane.h header drm/exynos: remove spare macro drm/exynos: drop exynos_drm_plane_config structure drm/exynos: add exynos_drm_crtc_init function drm/exynos/decon5433: embed exynos_drm_crtc directly into context drm/exynos/decon7: embed exynos_drm_crtc directly into context drm/exynos/fimd: embed exynos_drm_crtc directly into context drm/exynos/mixer: embed exynos_drm_crtc directly into context drm/exynos/vidi: embed exynos_drm_crtc directly into context drm/exynos: remove standalone exynos_drm_crtc leftovers drm/exynos/vidi: remove encoder_to_vidi helper drm/exynos: unify plane type assignment drm/exynos: set primary plane in exynos_drm_crtc_init drm/exynos: set cursor plane in exynos_drm_crtc_init drm/exynos: add plane update/disable callbacks for planes drm/exynos: add GSCALER plane capability drm/exynos/gscaler: fix id assignement drm/exynos/gscaler: add local path support drm/exynos/decon5433: add local path support drm/exynos/decon5433: wait for finish previous update drm/exynos/gscaler: change supported color format BGRX8888 to XBGR8888 drm/exynos/gscaler: fix handling YVU420 pixel format .../dts/exynos/exynos5433-tm2-common.dtsi | 6 + arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 +- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 ++++++++----- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 46 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 50 ++-- drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 85 +++---- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 229 ++++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_plane.c | 84 ++++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 48 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 95 +++----- drivers/gpu/drm/exynos/regs-decon5433.h | 6 + drivers/gpu/drm/exynos/regs-gsc.h | 6 + 18 files changed, 538 insertions(+), 408 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h -- 2.17.1

5 35

[Bug 121831] New: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '22

17 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=121831 Bug ID: 121831 Summary: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo Product: Drivers Version: 2.5 Kernel Version: 4.7-rc6 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: casteyde.christian(a)free.fr Regression: No Created attachment 222631 --> https://bugzilla.kernel.org/attachment.cgi?id=222631&action=edit dmesg output Slackware 64 14.1 With kmemcheck activated, I get the following warnings: [ 1185.586288] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8801c2cd5d08) [ 1185.586292] 000000000000000060f11c81ffffffff68509ab40188ffff0100010001000000 [ 1185.586314] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1185.586335] ^ [ 1185.586337] RIP: 0010:[<ffffffff8158521d>] [<ffffffff8158521d>] fence_signal+0x1d/0xe0 [ 1185.586343] RSP: 0018:ffff8801b560fa20 EFLAGS: 00010282 [ 1185.586345] RAX: 0000000000000003 RBX: ffff8801c2cd5cc0 RCX: 0000000000000002 [ 1185.586346] RDX: 0000000080000002 RSI: ffff8801b5591fa0 RDI: ffff8801c2cd5cc0 [ 1185.586348] RBP: ffff8801b560fa50 R08: 0000000000000000 R09: 0000000000000001 [ 1185.586349] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003 [ 1185.586350] R13: ffff8801c2cd5cc0 R14: 00000000021ae410 R15: ffff8800a9490000 [ 1185.586352] FS: 00007fe3e0e408c0(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1185.586353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1185.586355] CR2: ffff8801c7060c90 CR3: 00000001b558d000 CR4: 00000000000406f0 [ 1185.586356] [<ffffffff8148cb7a>] radeon_fence_signaled+0x4a/0x80 [ 1185.586360] [<ffffffff814f5cf7>] radeon_sa_bo_free+0x37/0xb0 [ 1185.586364] [<ffffffff81547f39>] radeon_ib_free+0x29/0x40 [ 1185.586369] [<ffffffff814a5105>] radeon_cs_parser_fini+0xc5/0x120 [ 1185.586372] [<ffffffff814a597b>] radeon_cs_ioctl+0x2fb/0x7d0 [ 1185.586374] [<ffffffff81449dce>] drm_ioctl+0x13e/0x530 [ 1185.586378] [<ffffffff81471b17>] radeon_drm_ioctl+0x47/0x80 [ 1185.586381] [<ffffffff811aebce>] do_vfs_ioctl+0x8e/0x670 [ 1185.586384] [<ffffffff811af1ec>] SyS_ioctl+0x3c/0x70 [ 1185.586386] [<ffffffff819434a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 1185.586391] [<ffffffffffffffff>] 0xffffffffffffffff [ 1197.075973] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4ac8) [ 1197.075977] 0200000000000000ffffffff3f000000ffffffff3f0000000000000000000000 [ 1197.075999] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1197.076019] ^ [ 1197.076021] RIP: 0010:[<ffffffff81584fc6>] [<ffffffff81584fc6>] fence_signal_locked+0x16/0xc0 [ 1197.076028] RSP: 0018:ffff8801c7403d18 EFLAGS: 00010082 [ 1197.076029] RAX: 000000000000001a RBX: ffff8800a2cf4b10 RCX: 0000000000000000 [ 1197.076031] RDX: ffff8800a9490000 RSI: 0000000000000003 RDI: ffff8800a2cf4a80 [ 1197.076032] RBP: ffff8801c7403d48 R08: 0000000000000000 R09: 0000000000000001 [ 1197.076033] R10: 0000000000000000 R11: ffffffff8200b540 R12: ffff8800a2cf4a80 [ 1197.076034] R13: ffff8800a9491ea8 R14: 0000000000000000 R15: 0000000000000003 [ 1197.076036] FS: 0000000000000000(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1197.076038] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1197.076039] CR2: ffff8801c29c016c CR3: 0000000002006000 CR4: 00000000000406f0 [ 1197.076040] [<ffffffff8148c571>] radeon_fence_check_signaled+0x41/0x80 [ 1197.076044] [<ffffffff810da49d>] __wake_up_common+0x4d/0x80 [ 1197.076334] [<ffffffff810da504>] __wake_up+0x34/0x50 [ 1197.076336] [<ffffffff8148c6c6>] radeon_fence_process+0x26/0x30 [ 1197.076338] [<ffffffff814e0caa>] evergreen_irq_process+0x92a/0x17e0 [ 1197.076342] [<ffffffff814a4309>] radeon_driver_irq_handler_kms+0x19/0x40 [ 1197.076345] [<ffffffff810f15e4>] handle_irq_event_percpu+0x64/0x100 [ 1197.076349] [<ffffffff810f16b4>] handle_irq_event+0x34/0x60 [ 1197.076352] [<ffffffff810f466e>] handle_edge_irq+0xbe/0x150 [ 1197.076356] [<ffffffff810617f8>] handle_irq+0x68/0x180 [ 1197.076360] [<ffffffff81060ff8>] do_IRQ+0x68/0x130 [ 1197.076362] [<ffffffff81943e09>] ret_from_intr+0x0/0x19 [ 1197.076367] [<ffffffff816fec82>] cpuidle_enter+0x12/0x20 [ 1197.076371] [<ffffffff810db0f5>] call_cpuidle+0x25/0x40 [ 1197.076373] [<ffffffff810db3c3>] cpu_startup_entry+0x1b3/0x290 [ 1197.076375] [<ffffffff8193ad5c>] rest_init+0x12c/0x140 [ 1197.076379] [<ffffffff82299de5>] start_kernel+0x354/0x361 [ 1197.076384] [<ffffffff822992ae>] x86_64_start_reservations+0x2f/0x31 [ 1197.076387] [<ffffffff8229939b>] x86_64_start_kernel+0xeb/0xf0 [ 1197.076390] [<ffffffffffffffff>] 0xffffffffffffffff [ 1207.836251] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4348) etc. In gdb: (gdb) l *0xffffffff8158521d 0xffffffff8158521d is in fence_signal (drivers/dma-buf/fence.c:114). 109 unsigned long flags; 110 111 if (!fence) 112 return -EINVAL; 113 114 if (!ktime_to_ns(fence->timestamp)) { 115 fence->timestamp = ktime_get(); 116 smp_mb__before_atomic(); 117 } -- You are receiving this mail because: You are watching the assignee of the bug.

2 3

[Bug 201539] New: AMDGPU R9 390 automatic fan speed control in Linux 4.19
by bugzilla-daemon＠bugzilla.kernel.org 05 Feb '22

05 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=201539 Bug ID: 201539 Summary: AMDGPU R9 390 automatic fan speed control in Linux 4.19 Product: Drivers Version: 2.5 Kernel Version: 4.19 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: 0xe2.0x9a.0x9b(a)gmail.com Regression: No GPU: R9 390 Kernel module: amdgpu Application (example): Rise of the Tomb Raider benchmark In Linux 4.18 the fan speed of the GPU gradually adapts to GPU load. Maximum pwm is 155 during the benchmark. In Linux 4.19 the overall fan speed is lower (which is more silent than 4.18, with maximum at 112) but the fan spikes to full speed (pwm=255) for 1-2 seconds which is extremely loud. The 4.18 and 4.19 kernels are using the same firmware. -- You are receiving this mail because: You are watching the assignee of the bug.

2 78

[Bug 204611] New: amdgpu error scheduling IBs when waking from sleep
by bugzilla-daemon＠bugzilla.kernel.org 30 Jan '22

30 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=204611 Bug ID: 204611 Summary: amdgpu error scheduling IBs when waking from sleep Product: Drivers Version: 2.5 Kernel Version: 5.2.9 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: tones111(a)hotmail.com Regression: No Created attachment 284485 --> https://bugzilla.kernel.org/attachment.cgi?id=284485&action=edit journalctl: amdgpu lockup on resume from sleep. My system locks up when trying to wake from sleep (open lid). The screen remains black and is unresponsive to keyboard/mouse input. I'm able to ssh from another machine and have attached the output from journalctl -b. The log shows scrolling errors... kernel: [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) kernel: amdgpu 0000:05:00.0: couldn't schedule ib on ring <gfx> This is a Lenovo E585 laptop with an AMD R5 2500U APU. -- You are receiving this mail because: You are watching the assignee of the bug.

2 15

[Bug 204559] New: amdgpu: kernel oops with constant gpu resets while using mpv
by bugzilla-daemon＠bugzilla.kernel.org 17 Jan '22

17 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=204559 Bug ID: 204559 Summary: amdgpu: kernel oops with constant gpu resets while using mpv Product: Drivers Version: 2.5 Kernel Version: 5.2.7 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: shoegaze(a)tutanota.com Regression: No Created attachment 284335 --> https://bugzilla.kernel.org/attachment.cgi?id=284335&action=edit oops.txt While watching a video using mpv (default config) the system will hang eventually - this is actually a kernel oops that happens after lots of GPU resets every second or so (in the span of ~5 minutes; it seems to be alright in the beginning): > Aug 12 00:46:49 mashedpotato kernel: [drm] UVD and UVD ENC initialized > successfully. > Aug 12 00:46:49 mashedpotato kernel: [drm] VCE initialized successfully. > Aug 12 00:46:56 mashedpotato kernel: amdgpu 0000:01:00.0: GPU pci config > reset > Aug 12 00:46:59 mashedpotato kernel: [drm] PCIE GART of 256M enabled (table > at 0x000000F400000000). This block of warnings repeats itself many times and then it is this error: > Aug 12 00:52:20 mashedpotato kernel: amdgpu 0000:01:00.0: > [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring sdma0 test failed (-110) > Aug 12 00:52:20 mashedpotato kernel: [drm:amdgpu_device_resume [amdgpu]] > *ERROR* resume of IP block <sdma_v3_0> failed -110 > Aug 12 00:52:20 mashedpotato kernel: [drm:amdgpu_device_resume [amdgpu]] > *ERROR* amdgpu_device_ip_resume failed (-110). > Aug 12 00:52:25 mashedpotato kernel: BUG: kernel NULL pointer dereference, > address: 0000000000000000 > Aug 12 00:52:25 mashedpotato kernel: #PF: supervisor instruction fetch in > kernel mode > Aug 12 00:52:25 mashedpotato kernel: #PF: error_code(0x0010) - not-present > page In the end it is a kernel oops, log is in the attachment. The system is only recoverable via a hard reset afterwards, though the sound from a video keeps playing just fine. My system is a ASUS laptop, TUF FX505-DY with the latest BIOS. lspci: > 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root > Complex > 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU > 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 00h-1fh) PCIe Dummy Host Bridge > 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP > Bridge [6:0] > 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP > Bridge [6:0] > 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP > Bridge [6:0] > 00:01.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP > Bridge [6:0] > 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 00h-1fh) PCIe Dummy Host Bridge > 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal > PCIe GPP Bridge 0 to Bus A > 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev > 61) > 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev > 51) > 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 0 > 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 1 > 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 2 > 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 3 > 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 4 > 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 5 > 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 6 > 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device > 24: Function 7 > 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin > [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev e5) > 02:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. > Device 5008 (rev 01) > 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE > 802.11ac PCIe Wireless Network Adapter > 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) > 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Picasso (rev c2) > 05:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] > Raven/Raven2/Fenghuang HDMI/DP Audio Controller > 05:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h > (Models 10h-1fh) Platform Security Processor > 05:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 > 05:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 > 05:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 10h-1fh) HD Audio Controller I have amdgpu.gpu_reset=1 in my kernel commandline as I want to figure out another issue - sometimes the system hangs after locking and disabling screen, and I guess it is GPU reset-related. -- You are receiving this mail because: You are watching the assignee of the bug.

1 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019