dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board
by Julian Margetson 03 Jan '19

03 Jan '19

Kernels 4.03 and 4.04 oops with HDMI connection on Acube Sam460ex amcc 460ex powerpc board. 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 is the first bad commit commit 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 Author: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue Apr 7 09:52:42 2015 -0400 drm/radeon: only mark audio as connected if the monitor supports it (v3) commit 0f55db36d49d45b80eff0c0a2a498766016f458b upstream. Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> :040000 040000 de0366a6790f5c91d175bcb89cb34956bbe72b26 bbdb5734961f824558152c7c34a840c78bc3a9a9 M drivers [ 2.587570] Linux agpgart interface v0.103 [ 2.591997] [drm] Initialized drm 1.1.0 20060810 [ 2.596892] [drm] radeon kernel modesetting enabled. [ 2.602989] [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x1545:0x7750). [ 2.611161] [drm] register mmio base: 0xe90000000 [ 2.615935] [drm] register mmio size: 262144 [ 2.952043] ATOM BIOS: C44501 [ 2.955323] radeon 0001:81:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 2.964253] radeon 0001:81:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [ 2.971938] [drm] Detected VRAM RAM=1024M, BAR=256M [ 2.976840] [drm] RAM width 128bits DDR [ 2.980898] [TTM] Zone kernel: Available graphics memory: 379358 kiB [ 2.987383] [TTM] Zone highmem: Available graphics memory: 1034718 kiB [ 2.993934] [TTM] Initializing pool allocator [ 2.998331] [TTM] Initializing DMA pool allocator [ 3.003153] [drm] radeon: 1024M of VRAM memory ready [ 3.008162] [drm] radeon: 1024M of GTT memory ready. [ 3.013203] [drm] Loading verde Microcode [ 3.017266] [drm] Internal thermal controller with fan control [ 3.023437] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0 [ 3.077284] [drm] radeon: dpm initialized [ 3.081503] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 3.093142] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0 [ 3.125984] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000). [ 3.133327] radeon 0001:81:00.0: WB enabled [ 3.137565] radeon 0001:81:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffc01c00 [ 3.147697] radeon 0001:81:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffc01c04 [ 3.157827] radeon 0001:81:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffc01c08 [ 3.167957] radeon 0001:81:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffc01c0c [ 3.178078] radeon 0001:81:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffc01c10 [ 3.209673] radeon 0001:81:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xf90b5a18 [ 3.219822] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.226457] [drm] Driver supports precise vblank timestamp query. [ 3.232584] radeon 0001:81:00.0: radeon: MSI limited to 32-bit [ 3.238466] ppc4xx_setup_msi_irqs: fail allocating msi interrupt [ 3.244586] [drm] radeon: irq initialized. [ 4.006339] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [ 4.015198] radeon 0001:81:00.0: disabling GPU acceleration [ 4.220071] [drm] Radeon Display Connectors [ 4.224651] [drm] Connector 0: [ 4.227787] [drm] HDMI-A-1 [ 4.230754] [drm] HPD4 [ 4.233328] [drm] DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c 0x657c [ 4.240806] [drm] Encoders: [ 4.243815] [drm] DFP1: INTERNAL_UNIPHY2 [ 4.248131] [drm] Connector 1: [ 4.251227] [drm] DVI-I-1 [ 4.254051] [drm] HPD2 [ 4.256608] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c [ 4.264034] [drm] Encoders: [ 4.267021] [drm] DFP2: INTERNAL_UNIPHY [ 4.271223] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 4.390562] [drm] fb mappable at 0x80478000 [ 4.394789] [drm] vram apper at 0x80000000 [ 4.398905] [drm] size 8294400 [ 4.401978] [drm] fb depth is 24 [ 4.405225] [drm] pitch is 7680 [ 4.700581] Console: switching to colour frame buffer device 240x67 [ 4.779669] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device [ 4.786489] radeon 0001:81:00.0: registered panic notifier [ 4.796803] [drm] Initialized radeon 2.41.0 20080528 for 0001:81:00.0 on minor 0 [ 31.191562] Unable to handle kernel paging request for data at address 0x00000008 [ 31.258832] Faulting instruction address: 0xc04a51bc [ 34.049506] Oops: Kernel access of bad area, sig: 11 [#1] [ 34.055246] PREEMPT Canyonlands [ 34.058586] Modules linked in: [ 34.061830] CPU: 0 PID: 1998 Comm: Xorg Not tainted 4.0.3-Sam460ex #2 [ 34.068633] task: edee4c60 ti: ede8a000 task.ti: ede8a000 [ 34.074334] NIP: c04a51bc LR: c04a546c CTR: c03e5050 [ 34.079578] REGS: ede8bc30 TRAP: 0300 Not tainted (4.0.3-Sam460ex) [ 34.086381] MSR: 00029000 <CE,EE,ME> CR: 20004422 XER: 00000000 [ 34.092944] DEAR: 00000008 ESR: 00000000 GPR00: c04a5438 ede8bce0 edee4c60 eea84000 00000000 00000000 c0710000 00000000 GPR08: 00000000 00000000 eeac0400 ede8bce0 20004444 b7a55afc b80efab0 b80ee530 GPR16: 00000000 ffffffff 6f23c730 ede8be18 c03add44 eeac0578 00000001 00004000 GPR24: 00004000 c0719b98 fffffff2 00000001 eeb61200 eea84000 eea8df00 00000000 [ 34.127485] NIP [c04a51bc] radeon_audio_enable+0x4/0x18 [ 34.133000] LR [c04a546c] radeon_audio_detect+0xd4/0x104 [ 34.138604] Call Trace: [ 34.141185] [ede8bce0] [c04a5438] radeon_audio_detect+0xa0/0x104 (unreliable) [ 34.148771] [ede8bd00] [c03e6958] radeon_dvi_detect+0x390/0x3b4 [ 34.155046] [ede8bd30] [c0391cec] drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x448 [ 34.164253] [ede8bd70] [c03ade28] drm_mode_getconnector+0xe4/0x334 [ 34.170796] [ede8be10] [c03a0be8] drm_ioctl+0x348/0x464 [ 34.176343] [ede8bed0] [c00ce2e8] do_vfs_ioctl+0x52c/0x6e8 [ 34.182158] [ede8bf20] [c00ce4e4] SyS_ioctl+0x40/0x68 [ 34.187515] [ede8bf40] [c000ab1c] ret_from_syscall+0x0/0x3c [ 34.193417] --- interrupt: c01 at 0x6fb001dc [ 34.193417] LR = 0x6fb00100 [ 34.201216] Instruction dump: [ 34.204368] 8129012c 806a0018 2f890000 419e0018 81290004 2f890000 419e000c 7d2903a6 [ 34.212674] 4e800420 38600000 4e800020 81231cd8 <81290008> 2f890000 4d9e0020 7d2903a6 [ 34.376219] ---[ end trace 803e15e46b991816 ]--- [ 34.380843] * Starting Mount filesystems on boot[ OK ] *

6 26

[PATCH] fb: fix lost console when the user unplugs a USB adapter
by Mikulas Patocka 31 Dec '18

31 Dec '18

I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board. The reason is this: When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it. This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/video/fbdev/core/fbmem.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) Index: linux-4.16.12/drivers/video/fbdev/core/fbmem.c =================================================================== --- linux-4.16.12.orig/drivers/video/fbdev/core/fbmem.c 2018-05-26 06:13:20.000000000 +0200 +++ linux-4.16.12/drivers/video/fbdev/core/fbmem.c 2018-05-26 06:13:20.000000000 +0200 @@ -1805,12 +1805,12 @@ static int do_register_framebuffer(struc return 0; } -static int do_unregister_framebuffer(struct fb_info *fb_info) +static int unbind_console(struct fb_info *fb_info) { struct fb_event event; - int i, ret = 0; + int ret; + int i = fb_info->node; - i = fb_info->node; if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info) return -EINVAL; @@ -1825,6 +1825,16 @@ static int do_unregister_framebuffer(str unlock_fb_info(fb_info); console_unlock(); + return ret; +} + +static int do_unregister_framebuffer(struct fb_info *fb_info) +{ + struct fb_event event; + int ret; + + ret = unbind_console(fb_info); + if (ret) return -EINVAL; @@ -1835,7 +1845,7 @@ static int do_unregister_framebuffer(str (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT)) kfree(fb_info->pixmap.addr); fb_destroy_modelist(&fb_info->modelist); - registered_fb[i] = NULL; + registered_fb[fb_info->node] = NULL; num_registered_fb--; fb_cleanup_device(fb_info); event.info = fb_info; @@ -1860,6 +1870,9 @@ int unlink_framebuffer(struct fb_info *f device_destroy(fb_class, MKDEV(FB_MAJOR, i)); fb_info->dev = NULL; } + + unbind_console(fb_info); + return 0; } EXPORT_SYMBOL(unlink_framebuffer);

6 18

[Bug 200531] New: amdgpu: *ERROR* REG_WAIT timeout when a display is put to sleep
by bugzilla-daemon＠bugzilla.kernel.org 31 Dec '18

31 Dec '18

https://bugzilla.kernel.org/show_bug.cgi?id=200531 Bug ID: 200531 Summary: amdgpu: *ERROR* REG_WAIT timeout when a display is put to sleep Product: Drivers Version: 2.5 Kernel Version: 4.17.6 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: mezin.alexander(a)gmail.com Regression: No Created attachment 277391 --> https://bugzilla.kernel.org/attachment.cgi?id=277391&action=edit dmesg When a display is turned off (because of inactivity), sometimes I see "*ERROR* REG_WAIT timeout" from amdgpu in the kernel log. And sometimes when the display wakes up, GUI doesn't respond anymore (even mouse pointer isn't moving). full dmesg output attached card: RX Vega 64 (Sapphire Nitro+) I think it started with 4.17.5 or 4.17.6, i'll try to find the exact commit -- You are receiving this mail because: You are watching the assignee of the bug.

1 14

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.
by bugzilla-daemon＠freedesktop.org 20 Dec '18

20 Dec '18

https://bugs.freedesktop.org/show_bug.cgi?id=104275 Bug ID: 104275 Summary: Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode. Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: kai.heng.feng(a)canonical.com Hi, We are enabling a new Stoney Ridge laptop. The issue can be reproduced on branch drm-next-4.16-wip and amd-staging-drm-next. Reproduce steps: 1. Plug HDMI monitor. 2. Change to extended mode. 3. Unplug the HDMI monitor 4. Plug the HDMI monitor Internal display may go blank in step 3. The internal display may also go blank in step 4. The external one shows desktop correctly though. I can see lots of message flooding once I plugged HDMI: [ 120.933668] amdgpu 0000:00:01.0: 0000000030e07f1f pin failed [ 120.933859] [drm:amdgpu_crtc_page_flip_target [amdgpu]] *ERROR* failed to pin new abo buffer before flip These messages stop as soon as the HDMI is unplugged. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[PATCH 0/3] Finish Armada DRM DT support
by Russell King - ARM Linux 18 Dec '18

18 Dec '18

Finish Armada DRM support for DT, finally allowing mainline kernels to use this driver unimpeded. arch/arm/boot/dts/dove-cubox.dts | 43 +++++++++++++++++++++++++++++++ drivers/gpu/drm/armada/Makefile | 3 +++ drivers/gpu/drm/armada/armada_drv.c | 29 ++++++++++++++++++--- drivers/gpu/drm/armada/armada_rmem.c | 49 ++++++++++++++++++++++++++++++++++++ 4 files changed, 121 insertions(+), 3 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up

6 46

[PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP
by Laurent Pinchart 18 Dec '18

18 Dec '18

Hello everybody, This patch series fixes two issues related to dma-buf import for the Renesas R-Car DU when the imported buffer is either not physically contiguous or located in high memory. Both cases require the use of an IOMMU to remap the buffers contiguously and in 32-bit DMA space. On Gen2 platforms this is transparent and works already, but on Gen3 platforms the situation is more complex. The Gen3 DU doesn't perform DMA access directly but instead goes through a VSP IP core that acts as an external composer. When importing a dma-buf buffer the GEM PRIME helper drm_gem_prime_import() maps the buffer to the DU device, and the DU driver later remaps it to the VSP device. The driver unfortunately can't use the drm_gem_prime_import_dev() helper to map th buffer to the VSP device directly, as at import time we don't know yet to which VSP device the buffer will need to be mapped (there is one VSP composer per CRTC). Mapping the buffer to the VSP can thus only be done when pinning the framebuffer, as we know at that time which plane and CRTC it will be used with. This works currently (with the caveat that an unneeded mapping to the DU is created), but fails when the imported buffer is not physically contiguous or is located in high memory. In the first case the GEM CMA helper drm_gem_cma_prime_import_sg_table() will reject the buffer as it hasn't been mapped contiguously in the DU DMA address space (because the DU has no IOMMU), and in the second case the DMA mapping API will try to allocate a bounce buffer and fail due to bounce buffer memory exhaustion. The first patch in this series fixes the second issue by setting the DMA coherent mask of the DU device to the full 40 bits address space. All memory will thus be accepted without trying to allocate a bounce buffer. The second patch in this series fixes the first issue by using an internal copy of the drm_gem_cma_prime_import_sg_table() function that doesn't ensure that the buffer is contiguous in memory. This is what caused me to post this series as an RFC, as I'm not very happy with duplication of helper code in the driver that could lead to breakages when the GEM CMA helpers are modified. If this approach is accepted, I would prefer implementing the code in the GEM CMA helpers. Another point that bothers me is that buffers can now be imported unconditionally on Gen3 platforms, but atomic commits will fail if the buffer can't be remapped through the VSP (for instance if no IOMMU is available). Given the hardware architecture and the DRM/KMS API I don't really see a way around this. Testing this series isn't easy as it requires getting hold of exported dma-bufs located in high memory or not physically contiguous. I have used the V4L2 vivid driver as an exporter for that purpose, with a few hacks that can be found at git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu On the userspace side I have used the v4l2-drm-example test application available at git://git.infradead.org/users/kmpark/public-apps and run with dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \ -s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2 (the -o argument needs to be modified based on the connector and CRTC ID). Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers from high memory" then breaks buffer import, and the issue is fixed by patch "drm: rcar-du: Set the DMA coherent mask for the DU device". Patch "[HACK] vivid: Use vmalloc allocator" breaks buffer import again, and is fixed by "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP". Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and haven't noticed any problem, but couldn't check the output on the screen. Would you be able to rerun the test locally for me ? Please note that the IPMMU is known to have issues on H3 ES1.1, so you might need to test the code on H3 ES2.0 instead. Laurent Pinchart (2): drm: rcar-du: Set the DMA coherent mask for the DU device drm: rcar-du: Allow importing non-contiguous dma-buf with VSP drivers/gpu/drm/rcar-du/rcar_du_drv.c | 13 +++++++++++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++++++++++++++++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 7 +++++++ 3 files changed, 58 insertions(+), 1 deletion(-) -- Regards, Laurent Pinchart

4 9

[Bug 115431] New: radeon 0000:01:00.0: VCE init error (-22).
by bugzilla-daemon＠bugzilla.kernel.org 17 Dec '18

17 Dec '18

https://bugzilla.kernel.org/show_bug.cgi?id=115431 Bug ID: 115431 Summary: radeon 0000:01:00.0: VCE init error (-22). Product: Drivers Version: 2.5 Kernel Version: 4.4.6-300.fc23.x86_64 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: luya(a)fedoraproject.org Regression: No Created attachment 210941 --> https://bugzilla.kernel.org/attachment.cgi?id=210941&action=edit dmesg boot report The issue occurred at the boot: [25494.592428] radeon 0000:01:00.0: VCE init error (-22). The bug was originally reported on Red Hat Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1295627 Hardware used is a ASUS X550ZE powered by am APU Kaveri chipset. -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[PATCH] drm/sun4i: fix HSYNC and VSYNC polarity
by Giulio Benetti 13 Dec '18

13 Dec '18

Differently from other Lcd signals, HSYNC and VSYNC signals result inverted if their bits are cleared to 0. Invert their settings of IO_POL register. Signed-off-by: Giulio Benetti <giulio.benetti(a)micronovasrl.com> --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 3c15cf2..aaf911a 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, SUN4I_TCON0_BASIC3_H_SYNC(hsync)); /* Setup the polarity of the various signals */ - if (!(mode->flags & DRM_MODE_FLAG_PHSYNC)) + if (mode->flags & DRM_MODE_FLAG_PHSYNC) val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE; - if (!(mode->flags & DRM_MODE_FLAG_PVSYNC)) + if (mode->flags & DRM_MODE_FLAG_PVSYNC) val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE; regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG, -- 2.7.4

4 12

[Bug 199319] New: Flickering screen on AMDGPU and DC with Linux 4.16-2
by bugzilla-daemon＠bugzilla.kernel.org 12 Dec '18

12 Dec '18

https://bugzilla.kernel.org/show_bug.cgi?id=199319 Bug ID: 199319 Summary: Flickering screen on AMDGPU and DC with Linux 4.16-2 Product: Drivers Version: 2.5 Kernel Version: Linux 4.16 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: mail(a)rainer-finke.de Regression: No Description: I upgraded to Linux 4.16-2 from the Arch Linux testing repository, but since then the screen is flickering with my RX480 and AMDGPU.DC enabled. The flickering is visible especially on Plasma-Wayland as soon as I move the mouse, it is like a bright flickering, not like a graphical corruption. On SDDM or Plasma X11 the flickering is much less frequent, but even there the screen flickers from time to time. I use a 4K display connected via DisplayPort. A downgrade to Linux 4.15 stable solved this even tough AMDGPU.DC is enabled as well. I couldn't reproduce the same issue with my AMD Ryzen 5 2500U Vega APU (1920x1080), so the issue might be related to the RX480 or 4K. Additional info: * Linux 4.16-2 from Arch Linux testing * AMDGPU.DC=1 (kernel parameter) * 4K display DisplayPort Steps to reproduce: 1. Ugrade to Linux 4.16.2 with AMDGPU.DC enabled on a RX480 2. Screen is flickering when moving the mouse -- You are receiving this mail because: You are watching the assignee of the bug.

1 22

[Bug 105018] Kernel panic when waking up after screen goes blank.
by bugzilla-daemon＠freedesktop.org 10 Dec '18

10 Dec '18

https://bugs.freedesktop.org/show_bug.cgi?id=105018 Bug ID: 105018 Summary: Kernel panic when waking up after screen goes blank. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: ragnaros39216(a)yandex.com I'm currently running on latest Manjaro XFCE with the 4.15 kernel just released, and I found that the system would crash when trying to wake up after the screen went blank. The system is an AMD Laptop (ASUS ROG STRIX GL702ZC), and the problem is 100% reproducible with the following steps: - Lock the screen, leave the screen blank for at least 3-5 minutes. - Try wake the screen up, like moving the mouse cursor. At first I did not find the cause, but after looking into the journalctl I was able to find something that appears to be a kernel panic. It existed since the beginning, with the 4.14 kernel, and remained unsolved even after upgrading to 4.15 kernel. Feb 07 11:48:59 linuxsys kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Feb 07 11:48:59 linuxsys kernel: IP: dce110_vblank_set+0x4f/0xb0 [amdgpu] Feb 07 11:48:59 linuxsys kernel: PGD 7e2ac2067 P4D 7e2ac2067 PUD 7e2a7e067 PMD 0 Feb 07 11:48:59 linuxsys kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI Feb 07 11:48:59 linuxsys kernel: Modules linked in: vmw_vsock_vmci_transport vsock rfcomm fuse bnep vmnet(O) arc4 amdkfd nls_iso8859_1 amd_iommu_v2 nls_cp437 vfat fat amdgpu iwlmvm uvcvideo mac80211 videobuf2_vmalloc edac_mce_amd btusb vide Feb 07 11:48:59 linuxsys kernel: rng_core cryptd pcspkr k10temp i2c_piix4 shpchp battery wmi thermal ac tpm_crb tpm_tis tpm_tis_core video tpm asus_wireless i2c_hid button acpi_cpufreq sch_fq_codel vmmon(O) vmw_vmci vboxnetflt(O) vboxnetad Feb 07 11:48:59 linuxsys kernel: CPU: 15 PID: 1467 Comm: xfwm4 Tainted: G W O 4.15.0-1-MANJARO #1 Feb 07 11:48:59 linuxsys kernel: Hardware name: ASUSTeK COMPUTER INC. GL702ZC/GL702ZC, BIOS GL702ZC.303 12/15/2017 Feb 07 11:48:59 linuxsys kernel: RIP: 0010:dce110_vblank_set+0x4f/0xb0 [amdgpu] Feb 07 11:48:59 linuxsys kernel: RSP: 0018:ffffb4e388c7bbe0 EFLAGS: 00010002 Feb 07 11:48:59 linuxsys kernel: RAX: ffff9b458850c000 RBX: 0000000000000001 RCX: 0000000000000000 Feb 07 11:48:59 linuxsys kernel: RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 Feb 07 11:48:59 linuxsys kernel: RBP: ffff9b4b2f4168e0 R08: 0000000000000000 R09: 0000000000000000 Feb 07 11:48:59 linuxsys kernel: R10: 00007fff89afe9f0 R11: ffff9b4b2b86ac40 R12: ffff9b4b38511a80 Feb 07 11:48:59 linuxsys kernel: R13: ffffffffc12bbba0 R14: ffff9b4b281f0000 R15: ffff9b4b3ab4cb68 Feb 07 11:48:59 linuxsys kernel: FS: 00007f0bdae66980(0000) GS:ffff9b4b3e9c0000(0000) knlGS:0000000000000000 Feb 07 11:48:59 linuxsys kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 07 11:48:59 linuxsys kernel: CR2: 0000000000000000 CR3: 00000007d96c8000 CR4: 00000000003406e0 Feb 07 11:48:59 linuxsys kernel: Call Trace: Feb 07 11:48:59 linuxsys kernel: amdgpu_dm_set_crtc_irq_state+0x31/0x60 [amdgpu] Feb 07 11:48:59 linuxsys kernel: amdgpu_irq_update+0x55/0x90 [amdgpu] Feb 07 11:48:59 linuxsys kernel: drm_vblank_enable+0x84/0x100 [drm] Feb 07 11:48:59 linuxsys kernel: drm_vblank_get+0x8d/0xb0 [drm] Feb 07 11:48:59 linuxsys kernel: drm_wait_vblank_ioctl+0x12a/0x690 [drm] Feb 07 11:48:59 linuxsys kernel: ? unix_stream_recvmsg+0x53/0x70 Feb 07 11:48:59 linuxsys kernel: ? drm_legacy_modeset_ctl_ioctl+0x100/0x100 [drm] Feb 07 11:48:59 linuxsys kernel: drm_ioctl_kernel+0x5b/0xb0 [drm] Feb 07 11:48:59 linuxsys kernel: drm_ioctl+0x2d5/0x370 [drm] Feb 07 11:48:59 linuxsys kernel: ? drm_legacy_modeset_ctl_ioctl+0x100/0x100 [drm] Feb 07 11:48:59 linuxsys kernel: ? do_iter_write+0xdc/0x190 Feb 07 11:48:59 linuxsys kernel: ? vfs_writev+0xb9/0x110 Feb 07 11:48:59 linuxsys kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Feb 07 11:48:59 linuxsys kernel: do_vfs_ioctl+0xa4/0x630 Feb 07 11:48:59 linuxsys kernel: ? __sys_recvmsg+0x4e/0x90 Feb 07 11:48:59 linuxsys kernel: ? __sys_recvmsg+0x7d/0x90 Feb 07 11:48:59 linuxsys kernel: SyS_ioctl+0x74/0x80 Feb 07 11:48:59 linuxsys kernel: entry_SYSCALL_64_fastpath+0x20/0x83 Feb 07 11:48:59 linuxsys kernel: RIP: 0033:0x7f0bd74b3d87 Feb 07 11:48:59 linuxsys kernel: RSP: 002b:00007fff89afea38 EFLAGS: 00000246 Feb 07 11:48:59 linuxsys kernel: Code: e8 17 20 04 00 83 e8 4e 0f b6 d0 48 89 d0 48 c1 e0 05 48 01 d0 48 c1 e0 05 49 03 86 60 01 00 00 84 db 48 8b b8 78 02 00 00 74 18 <48> 8b 07 be 02 00 00 00 48 8b 80 d8 00 00 00 e8 6d 43 7e ee 84 Feb 07 11:48:59 linuxsys kernel: RIP: dce110_vblank_set+0x4f/0xb0 [amdgpu] RSP: ffffb4e388c7bbe0 Feb 07 11:48:59 linuxsys kernel: CR2: 0000000000000000 Feb 07 11:48:59 linuxsys kernel: ---[ end trace 36522610c84ff0f3 ]--- The cause seems to be dce110_vblank_set+0x4f/0xb0 [amdgpu], with the topmost call trace being dce110_vblank_set+0x4f/0xb0 [amdgpu]. The bug report here, which was closed last December, resembled my current issue: https://lists.freedesktop.org/archives/amd-gfx/2017-November/016236.html I've thought about the possibility of it being DC-related as I saw similar bug reports, but I was wrong, as at one time I was able to reproduce it even after passing amdgpu.dc=0 during boot. The modules don't seem to be related, as it happened on fresh installs, where I left the screen blank (before I actually adjusted power management options) as I let it download and install packages I wanted in the background. Additionally, I'm able to find some additional errors prior to the crash, which might have happened when the screen went blank. It could be done by simply locking the screen and leave it as is. (NOTE: When I locked the screen and then immediately move the mouse cursor to wake it up, the crash would not occur. It would only occur if the screen went blank for at least 3-5 minutes.) Feb 07 11:38:04 linuxsys kernel: [drm] {1920x1080, 2080x1111@138700Khz} Feb 07 11:38:12 linuxsys kernel: [drm] RBRx2 pass VS=1, PE=0 Feb 07 11:38:12 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:12 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:12 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:12 linuxsys kernel: WARNING: CPU: 12 PID: 1467 at drivers/gpu/drm/drm_vblank.c:612 drm_calc_vbltimestamp_from_scanoutpos+0x2c5/0x340 [drm] Feb 07 11:38:12 linuxsys kernel: Modules linked in: vmw_vsock_vmci_transport vsock rfcomm fuse bnep vmnet(O) arc4 amdkfd nls_iso8859_1 amd_iommu_v2 nls_cp437 vfat fat amdgpu iwlmvm uvcvideo mac80211 videobuf2_vmalloc edac_mce_amd btusb vide Feb 07 11:38:12 linuxsys kernel: rng_core cryptd pcspkr k10temp i2c_piix4 shpchp battery wmi thermal ac tpm_crb tpm_tis tpm_tis_core video tpm asus_wireless i2c_hid button acpi_cpufreq sch_fq_codel vmmon(O) vmw_vmci vboxnetflt(O) vboxnetad Feb 07 11:38:12 linuxsys kernel: CPU: 12 PID: 1467 Comm: xfwm4 Tainted: G O 4.15.0-1-MANJARO #1 Feb 07 11:38:12 linuxsys kernel: Hardware name: ASUSTeK COMPUTER INC. GL702ZC/GL702ZC, BIOS GL702ZC.303 12/15/2017 Feb 07 11:38:12 linuxsys kernel: RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x2c5/0x340 [drm] Feb 07 11:38:12 linuxsys kernel: RSP: 0018:ffffb4e388c7bb50 EFLAGS: 00010086 Feb 07 11:38:12 linuxsys kernel: RAX: ffffffffc12b04c0 RBX: ffff9b4b3ab4c800 RCX: 0000000000000001 Feb 07 11:38:12 linuxsys kernel: RDX: ffffffffc0941068 RSI: 0000000000000001 RDI: ffffffffc093f0d8 Feb 07 11:38:12 linuxsys kernel: RBP: ffffb4e388c7bbb8 R08: 0000000000000000 R09: ffffffffc09214a0 Feb 07 11:38:12 linuxsys kernel: R10: ffffffffc10d6320 R11: ffffffffb056c36d R12: 0000000000000001 Feb 07 11:38:12 linuxsys kernel: R13: ffffb4e388c7bbcc R14: ffffb4e388c7bc00 R15: ffff9b4b2ba84000 Feb 07 11:38:12 linuxsys kernel: FS: 00007f0bdae66980(0000) GS:ffff9b4b3e900000(0000) knlGS:0000000000000000 Feb 07 11:38:12 linuxsys kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 07 11:38:12 linuxsys kernel: CR2: 00007f9ee41080b0 CR3: 00000007d96c8000 CR4: 00000000003406e0 Feb 07 11:38:12 linuxsys kernel: Call Trace: Feb 07 11:38:12 linuxsys kernel: drm_get_last_vbltimestamp+0x54/0x90 [drm] Feb 07 11:38:12 linuxsys kernel: drm_update_vblank_count+0x77/0x250 [drm] Feb 07 11:38:12 linuxsys kernel: drm_vblank_enable+0xbd/0x100 [drm] Feb 07 11:38:12 linuxsys kernel: drm_vblank_get+0x8d/0xb0 [drm] Feb 07 11:38:12 linuxsys kernel: drm_wait_vblank_ioctl+0x12a/0x690 [drm] Feb 07 11:38:12 linuxsys kernel: ? unix_stream_recvmsg+0x53/0x70 Feb 07 11:38:12 linuxsys kernel: ? drm_legacy_modeset_ctl_ioctl+0x100/0x100 [drm] Feb 07 11:38:12 linuxsys kernel: drm_ioctl_kernel+0x5b/0xb0 [drm] Feb 07 11:38:12 linuxsys kernel: drm_ioctl+0x2d5/0x370 [drm] Feb 07 11:38:12 linuxsys kernel: ? drm_legacy_modeset_ctl_ioctl+0x100/0x100 [drm] Feb 07 11:38:12 linuxsys kernel: ? do_iter_write+0xdc/0x190 Feb 07 11:38:12 linuxsys kernel: ? vfs_writev+0xb9/0x110 Feb 07 11:38:12 linuxsys kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Feb 07 11:38:12 linuxsys kernel: do_vfs_ioctl+0xa4/0x630 Feb 07 11:38:12 linuxsys kernel: ? __sys_recvmsg+0x4e/0x90 Feb 07 11:38:12 linuxsys kernel: ? __sys_recvmsg+0x7d/0x90 Feb 07 11:38:12 linuxsys kernel: SyS_ioctl+0x74/0x80 Feb 07 11:38:12 linuxsys kernel: entry_SYSCALL_64_fastpath+0x20/0x83 Feb 07 11:38:12 linuxsys kernel: RIP: 0033:0x7f0bd74b3d87 Feb 07 11:38:12 linuxsys kernel: RSP: 002b:00007fff89afea38 EFLAGS: 00000246 Feb 07 11:38:12 linuxsys kernel: Code: e1 48 c7 c2 68 10 94 c0 be 01 00 00 00 48 c7 c7 d8 f0 93 c0 e8 1d 66 fe ff 48 8b 83 98 03 00 00 48 83 78 20 00 0f 84 6f fd ff ff <0f> ff e9 68 fd ff ff 48 c7 c2 30 10 94 c0 31 f6 48 c7 c7 d5 f0 Feb 07 11:38:12 linuxsys kernel: ---[ end trace 36522610c84ff0f2 ]--- Feb 07 11:38:12 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:12 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:12 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! Feb 07 11:38:20 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! For now, I could only prevent the panic from happening by not allowing power saving functions to happen, especially anything that would turn off the screen. I'm also not allowed to lock the screen it would also blank the screen, and the GTK+ greeter could blank the screen in its own way. However, it's not feasible for running the system on battery for an extended period without any power saving feature, given the high total TDP the laptop has, and leaving the system unlocked is a bad idea in terms of security and privacy. By the way, given there were a few similar closed bug reports in the past, I believe the problem might be a regression. -- You are receiving this mail because: You are the assignee for the bug.

1 43

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018