dri-devel April 2019

dri-devel@lists.freedesktop.org

307 participants
2114 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

[PATCH 1/3] drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly
by ville.syrjala＠linux.intel.com 12 Jan '22

12 Jan '22

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: stable(a)vger.kernel.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index bfd237c15e76..18cecd94acb6 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2515,8 +2515,8 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, int req_slots; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); port = drm_dp_get_validated_port_ref(mgr, port); if (port == NULL) @@ -2555,8 +2555,8 @@ int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_state *topology_state; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent -- 2.13.0

4 7

[Bug 53391] New: nouveau: wrong display output order
by bugzilla-daemon＠bugzilla.kernel.org 08 Dec '21

08 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=53391 Summary: nouveau: wrong display output order Product: Drivers Version: 2.5 Kernel Version: 3.8-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: stijn+bugs(a)linux-ipv6.be Regression: No My graphics card is a Gainward GTX480 (http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1 mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being the closest to the PCIe slot, then DVI 2, and finally the mini HDMI. My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor on DVI 1. Grub is displayed on the primary monitor, and the kernel initially outputs to the primary monitor as well. However, as soon as the nouveau module is loaded, the primary monitor goes to standby and the kernel now uses the secondary monitor (on DVI 2) as primary. When X starts (no Xorg.conf file), it is also displayed on the secondary monitor. When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the primary monitor. X with nvidia.ko also uses DVI 1 as the primary display. Finally, when booting Windows, the startup screen is also displayed on the monitor connected to DVI 1. Here comes the weird part: when I am in X, and run xrandr, it does show 3 connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only active one. So it seems that in X, the output order is correct, but with nouveaufb the DVI connectors are swapped. I will attach the output of dmesg here. If anything else is needed, please let me know and I'll be happy to add it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 13

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2019