dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 204391] New: Overdrive on AMDGPU does not allow clocks above official clocks.
by bugzilla-daemon＠bugzilla.kernel.org 27 Oct '19

27 Oct '19

https://bugzilla.kernel.org/show_bug.cgi?id=204391 Bug ID: 204391 Summary: Overdrive on AMDGPU does not allow clocks above official clocks. Product: Drivers Version: 2.5 Kernel Version: 5.3rc1 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: haxk612(a)gmail.com Regression: No Created attachment 284063 --> https://bugzilla.kernel.org/attachment.cgi?id=284063&action=edit dmesg with Overdrive enabled. As the title of the bug says overdrive has a range that it operates in and thats good to not allow users to overclock the card to its death but there is a bug when overdrive is enabled it does not allow clocks for core or memory to be outside official clocks. I have RX560X with 1275 Mhz on Core and 1450Mhz on Memory and when i enable overdrive i can increase voltage suplied to core or memory but im not allowed to set any clock above the official clocks. If we try to do so it returns invalid argument as the file expected the clock to be in range. [ 914.519919] amdgpu: [powerplay] OD engine clock is out of range [214 - 1275] MHz [ 1096.096840] amdgpu: [powerplay] OD memory clock is out of range [300 - 1450] MHz I know for sure that this is not an GPU BIOS issue as in Windows we can indeed overclock the GPU way above the official clocks with some nice FPS boost in all games so the overclock there works. But whats weird is also that if we disable Overdrive im allowed to overclock Core frequency but im not able to overclock memory frequency. I think as im looking at the dmesg that it may have to do something with this: [ 383.163783] amdgpu: [powerplay] pp_dpm_get_sclk_od was not implemented. [ 383.163858] amdgpu: [powerplay] pp_dpm_get_mclk_od was not implemented. And indeed when trying to look into that file it does not exist anywhere. Only file that exists that is close to it is pp_dpm_mclk/sclk. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH v3 00/13] Conversion of panel bindings to DT schema
by Rob Herring 25 Oct '19

25 Oct '19

This series converts the common panel bindings to DT schema format. Besides the conversion of common panel properties, a few panel bindings are converted here as well. These are all the ones with references to panel-common.txt or panel-lvds.txt. I'll apply the series to drm-misc. One patch from v2 already got applied without its dependency. v3: - Consistently list all used properties and add 'additionalProperties: false' Rob Rob Herring (13): dt-bindings: display: Convert common panel bindings to DT schema dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel to DT schema dt-bindings: display: Convert armadeus,st0700-adapt panel to DT schema dt-bindings: display: Convert bananapi,s070wv20-ct16 panel to DT schema dt-bindings: display: Convert dlc,dlc0700yzg-1 panel to DT schema dt-bindings: display: Convert pda,91-00156-a0 panel to DT schema dt-bindings: display: Convert raspberrypi,7inch-touchscreen panel to DT schema dt-bindings: display: Convert tfc,s9700rtwv43tr-01b panel to DT schema dt-bindings: display: Convert panel-lvds to DT schema dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema dt-bindings: display: Convert mitsubishi,aa104xd12 panel to DT schema dt-bindings: display: Convert mitsubishi,aa121td01 panel to DT schema dt-bindings: display: Convert sgd,gktw70sdae4se panel to DT schema .../panel/ampire,am-480272h3tmqw-t01h.txt | 26 --- .../panel/ampire,am-480272h3tmqw-t01h.yaml | 42 +++++ .../display/panel/arm,versatile-tft-panel.txt | 2 +- .../display/panel/armadeus,st0700-adapt.txt | 9 -- .../display/panel/armadeus,st0700-adapt.yaml | 33 ++++ .../display/panel/bananapi,s070wv20-ct16.txt | 12 -- .../display/panel/bananapi,s070wv20-ct16.yaml | 31 ++++ .../display/panel/dlc,dlc0700yzg-1.txt | 13 -- .../display/panel/dlc,dlc0700yzg-1.yaml | 31 ++++ .../display/panel/innolux,ee101ia-01d.txt | 7 - .../display/panel/innolux,ee101ia-01d.yaml | 31 ++++ .../bindings/display/panel/lvds.yaml | 107 +++++++++++++ .../display/panel/mitsubishi,aa104xd12.txt | 47 ------ .../display/panel/mitsubishi,aa104xd12.yaml | 75 +++++++++ .../display/panel/mitsubishi,aa121td01.txt | 47 ------ .../display/panel/mitsubishi,aa121td01.yaml | 74 +++++++++ .../bindings/display/panel/panel-common.txt | 101 ------------ .../bindings/display/panel/panel-common.yaml | 149 ++++++++++++++++++ .../bindings/display/panel/panel-lvds.txt | 121 -------------- .../bindings/display/panel/panel.txt | 4 - .../display/panel/pda,91-00156-a0.txt | 14 -- .../display/panel/pda,91-00156-a0.yaml | 31 ++++ .../panel/raspberrypi,7inch-touchscreen.txt | 49 ------ .../panel/raspberrypi,7inch-touchscreen.yaml | 71 +++++++++ .../display/panel/sgd,gktw70sdae4se.txt | 41 ----- .../display/panel/sgd,gktw70sdae4se.yaml | 68 ++++++++ .../bindings/display/panel/simple-panel.txt | 29 +--- .../display/panel/tfc,s9700rtwv43tr-01b.txt | 15 -- .../display/panel/tfc,s9700rtwv43tr-01b.yaml | 33 ++++ 29 files changed, 778 insertions(+), 535 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt create mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/lvds.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt delete mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt create mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt create mode 100644 Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt create mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt create mode 100644 Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml -- 2.20.1

2 17

[PATCH v1 1/3] gpu: host1x: Remove implicit IOMMU backing on client's registration
by Dmitry Osipenko 25 Oct '19

25 Oct '19

On ARM32 we don't want any of the clients device to be backed by the implicit domain, simply because we can't afford such a waste on older Tegra SoCs that have very few domains available in total. The recent IOMMU support addition for the Video Decoder hardware uncovered the problem that an unfortunate drivers probe order results in the DRM driver probe failure if CONFIG_ARM_DMA_USE_IOMMU=y due to a shortage of IOMMU domains caused by the implicit backing. The host1x_client_register() is a common function that is invoked by all of the relevant DRM drivers during theirs probe and hence it is convenient to remove the implicit backing there, resolving the problem. Signed-off-by: Dmitry Osipenko <digetx(a)gmail.com> --- drivers/gpu/host1x/bus.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c index 742aa9ff21b8..559df3974afb 100644 --- a/drivers/gpu/host1x/bus.c +++ b/drivers/gpu/host1x/bus.c @@ -14,6 +14,10 @@ #include "bus.h" #include "dev.h" +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) +#include <asm/dma-iommu.h> +#endif + static DEFINE_MUTEX(clients_lock); static LIST_HEAD(clients); @@ -710,6 +714,21 @@ int host1x_client_register(struct host1x_client *client) struct host1x *host1x; int err; +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) + /* + * The client's driver could be backed by implicit IOMMU mapping + * and we don't want to have that because all of current Tegra + * drivers are managing IOMMU by themselves. This is a convenient + * place for unmapping of the implicit mapping because this function + * is called by all host1x drivers during theirs probe. + */ + if (client->dev->archdata.mapping) { + struct dma_iommu_mapping *mapping = + to_dma_iommu_mapping(client->dev); + arm_iommu_detach_device(client->dev); + arm_iommu_release_mapping(mapping); + } +#endif mutex_lock(&devices_lock); list_for_each_entry(host1x, &devices, list) { -- 2.22.0

2 20

[PATCH] drm/syncobj: extend syncobj query ability v3
by Chunming Zhou 24 Oct '19

24 Oct '19

user space needs a flexiable query ability. So that umd can get last signaled or submitted point. v2: add sanitizer checking. v3: rebase Change-Id: I6512b430524ebabe715e602a2bf5abb0a7e780ea Signed-off-by: Chunming Zhou <david1.zhou(a)amd.com> Cc: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> Cc: Christian König <Christian.Koenig(a)amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> --- drivers/gpu/drm/drm_syncobj.c | 37 +++++++++++++++++++++-------------- include/uapi/drm/drm.h | 3 ++- 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index cecff2e447b1..d4432f1513ac 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -1197,7 +1197,7 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data, if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) return -EOPNOTSUPP; - if (args->pad != 0) + if (args->flags != 0) return -EINVAL; if (args->count_handles == 0) @@ -1268,7 +1268,7 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void *data, if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) return -EOPNOTSUPP; - if (args->pad != 0) + if (args->flags & ~DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED) return -EINVAL; if (args->count_handles == 0) @@ -1289,25 +1289,32 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void *data, fence = drm_syncobj_fence_get(syncobjs[i]); chain = to_dma_fence_chain(fence); if (chain) { - struct dma_fence *iter, *last_signaled = NULL; - - dma_fence_chain_for_each(iter, fence) { - if (iter->context != fence->context) { - dma_fence_put(iter); - /* It is most likely that timeline has - * unorder points. */ - break; + struct dma_fence *iter, *last_signaled = + dma_fence_get(fence); + + if (args->flags & + DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED) { + point = fence->seqno; + } else { + dma_fence_chain_for_each(iter, fence) { + if (iter->context != fence->context) { + dma_fence_put(iter); + /* It is most likely that timeline has + * unorder points. */ + break; + } + dma_fence_put(last_signaled); + last_signaled = dma_fence_get(iter); } - dma_fence_put(last_signaled); - last_signaled = dma_fence_get(iter); + point = dma_fence_is_signaled(last_signaled) ? + last_signaled->seqno : + to_dma_fence_chain(last_signaled)->prev_seqno; } - point = dma_fence_is_signaled(last_signaled) ? - last_signaled->seqno : - to_dma_fence_chain(last_signaled)->prev_seqno; dma_fence_put(last_signaled); } else { point = 0; } + dma_fence_put(fence); ret = copy_to_user(&points[i], &point, sizeof(uint64_t)); ret = ret ? -EFAULT : 0; if (ret) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 661d73f9a919..fd987ce24d9f 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -777,11 +777,12 @@ struct drm_syncobj_array { __u32 pad; }; +#define DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED (1 << 0) /* last available point on timeline syncobj */ struct drm_syncobj_timeline_array { __u64 handles; __u64 points; __u32 count_handles; - __u32 pad; + __u32 flags; }; -- 2.17.1

6 6

[Bug 204965] New: [amdgpu]] *ERROR* ring gfx test failed (-110) upon wake from sleep, no video or frozen video
by bugzilla-daemon＠bugzilla.kernel.org 23 Oct '19

23 Oct '19

https://bugzilla.kernel.org/show_bug.cgi?id=204965 Bug ID: 204965 Summary: [amdgpu]] *ERROR* ring gfx test failed (-110) upon wake from sleep, no video or frozen video Product: Drivers Version: 2.5 Kernel Version: 5.2.13-126.current 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: dav.per(a)gmx.com Regression: No Created attachment 285115 --> https://bugzilla.kernel.org/attachment.cgi?id=285115&action=edit journalctl bits Solus 4, issue has been present since an AMD card (RX580 4GB) was installed in this machine in july and has happened nine times. The machine, asleep, wakes up, fans and LEDs come on, but there is either no video signal out or there is a signal showing only a frozen screen of a clock when the machine fell asleep. No keyboard input has an effect. The machine still responds to pings over the network. DVI or DP interface makes no difference. Radeon RX 580 Series (POLARIS10 DRM 3.32.0 5.2.13-126.current LLVM 8.0.1) v: 4.5 Mesa 19.1.6 on Z170-HD3 mainboard, i7 6700 CPU. -- You are receiving this mail because: You are watching the assignee of the bug.

1 4

[Bug 110347] pp_od_clk_voltage mV cap ignored
by bugzilla-daemon＠freedesktop.org 23 Oct '19

23 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110347 Bug ID: 110347 Summary: pp_od_clk_voltage mV cap ignored Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bednarczyk.pawel(a)outlook.com Hi all, I have a Gigabyte Radeon RX Vega 64 GAMING OC 8GB and I have been playing with undervolting/overclocking the card for a better performance/power draw ratio. I have set the voltages/frequency as follows: https://gist.github.com/Bednar87/eeeee4fea34b03b96b2833e2900d3405 with voltage capped @ 950V Now of course prior to doing that I added the amdgpu.ppffeaturemask parameter to the boot line with value 0xfffd7fff. Looking at sudo watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info shows that the voltage is at 1200mV (VDDGFX). The power draw is also not reduced as one could expect from undervolting the clocks but instead shoots up to 320W and maintains this value under stress (50% power limit was also enabled). The frequency on the clocks seems to work fine and the settings seem to be honoured but the voltage value seems to be ignored. cat /sys/class/drm/card0/device/pp_od_clk_voltage OD_SCLK: 0: 852Mhz 800mV 1: 991Mhz 825mV 2: 1084Mhz 850mV 3: 1138Mhz 875mV 4: 1250Mhz 900mV 5: 1370Mhz 925mV 6: 1475Mhz 950mV 7: 1575Mhz 950mV OD_MCLK: 0: 167Mhz 800mV 1: 500Mhz 825mV 2: 800Mhz 865mV 3: 1050Mhz 950mV OD_RANGE: SCLK: 852MHz 2400MHz MCLK: 167MHz 1500MHz VDDC: 800mV 1200mV I am on Arch Linux kernel 5.0.6 MESA 19.0.1 -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 110113] AMD Vega64 issue setting custom voltages
by bugzilla-daemon＠freedesktop.org 23 Oct '19

23 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110113 Bug ID: 110113 Summary: AMD Vega64 issue setting custom voltages Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: wslatem(a)gmail.com I have been attempting to undervolt my Vega64 to reduce power consumption. I have tested the GPU under Fedora 29, running stock kernel 4.20 and mesa 18.3, and Mint 19.1, with Kernel 5.0 and mesa 19 and the issue is identical I have set the AMDgpu mask in grub to amdgpu.ppfeaturemask=0xffffffff. I can confirm the GPU accepts custom values that I write into pp_od_clk_voltage, and the GPU run on these, but the voltage create a strange profile. The voltages abide to the new settings, but only in the hysteresis/dead band around the clock in that P state. Soon as the clocks move out of this band, the voltages go max, i.e. 1.2V. Under 2D workload, the card seems fine, but soon as it is in 3D work loads, running in P5 and up, the voltage control is a problem, esspecialy if I'm at only 1450Mhz and running at 1.2V If I set P state, P6, to 1550MHz @ 1000mV and P7 to 1620MHz @ 1050mV and the clock is around 1550MHz, I will see that it has set the voltage to 1000mV, but if that freq increase to, say, 1580MHz, the GPU will be set to 1200mV. I suspected that maybe the reading I saw was incorrect, but it cannot be incorrect, as the GPU performs worse after the tweak, generally battling to leave P5 state, where stock clocks, it will stick closer to the P6 state clocks. My GPU also unfortunately has coil whine, but this does give audio cues with load and frame rate. The GPU changes pitch when it moves in and out of the set voltage. The GPU whine will be quieter when it landed in the reduced voltage state, and immediately increases once it jumps to the 1.2V state. The issue is also that it jumps between the reduced voltage and full voltage when it is boarder line, as the GPU starts to throttle when the voltages jump to 1.2V Essentially this is how I see the GPU react to my new voltage profile (leaving the clocks at stock). P5 P6 P7 -------| |-------------| |--------------| |-----1200mV |_____| |_____| |_____| 980mV 1000mV 1050mV So far all I can really change is the power state without causing issue, and this helps with performace when I increase it, at the cost of massive heat production -- You are receiving this mail because: You are the assignee for the bug.

1 2

[PATCH v1] drm/tegra: plane: Remove format-modifier checking
by Dmitry Osipenko 23 Oct '19

23 Oct '19

Tiling modifier can't be applied to YV12 video overlay because all tiling modifiers are filtered out for multi-plane formats. AFAIK, all modifiers should work with all of formats, hence the checking is incorrect and simply not needed. Fixes: e90124cb46bdb ("drm/tegra: plane: Support format modifiers") Signed-off-by: Dmitry Osipenko <digetx(a)gmail.com> --- drivers/gpu/drm/tegra/plane.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c index d068e8aa3553..5a8a3387f5ee 100644 --- a/drivers/gpu/drm/tegra/plane.c +++ b/drivers/gpu/drm/tegra/plane.c @@ -72,21 +72,6 @@ static void tegra_plane_atomic_destroy_state(struct drm_plane *plane, kfree(state); } -static bool tegra_plane_format_mod_supported(struct drm_plane *plane, - uint32_t format, - uint64_t modifier) -{ - const struct drm_format_info *info = drm_format_info(format); - - if (modifier == DRM_FORMAT_MOD_LINEAR) - return true; - - if (info->num_planes == 1) - return true; - - return false; -} - const struct drm_plane_funcs tegra_plane_funcs = { .update_plane = drm_atomic_helper_update_plane, .disable_plane = drm_atomic_helper_disable_plane, @@ -94,7 +79,6 @@ const struct drm_plane_funcs tegra_plane_funcs = { .reset = tegra_plane_reset, .atomic_duplicate_state = tegra_plane_atomic_duplicate_state, .atomic_destroy_state = tegra_plane_atomic_destroy_state, - .format_mod_supported = tegra_plane_format_mod_supported, }; int tegra_plane_state_add(struct tegra_plane *plane, -- 2.20.1

2 3

[Bug 94581] Red flood in dmesg when running applications
by bugzilla-daemon＠freedesktop.org 23 Oct '19

23 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=94581 Bug ID: 94581 Summary: Red flood in dmesg when running applications Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: mazahakaforever(a)ya.ru QA Contact: dri-devel(a)lists.freedesktop.org Hi there. Im using laptop with hybrid graphics. Intel Core i5-2450m with integrated videocard and AMD Radeon HD 6650m as discrete. My glxinfo output glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.0.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: And output with DRI_PRIME set. DRI_PRIME=1 glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.6.2) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.0.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: So, i guess when im using DRI_PRIME environmental variable as one - kernel tries to use discrete videocard. And when im trying to launch applications (glxgears, etracer, steam) i got many messages in dmesg like this [ 1376.309602] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xe [ 1376.309620] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! [ 1376.822639] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xe [ 1376.822661] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! Looking forward to some discussion. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 110574] System hang after screen power saving
by bugzilla-daemon＠freedesktop.org 22 Oct '19

22 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110574 Bug ID: 110574 Summary: System hang after screen power saving Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: number048(a)gmail.com Created attachment 144122 --> https://bugs.freedesktop.org/attachment.cgi?id=144122&action=edit dmesg After updating to Xubuntu 19.04 I started having problems with the screen saver feature. After a request for the monitor to go into power saving mode I am unable to recover the system. When the monitor turns on again I get the last image shown but I cannot move the cursor, nothing on the screen is moving, everything is frozen and I cannot use ssh to access the machine. Later I discovered that I could access the computer using ssh before I let the monitor enter power saving mode and I was then able to save a copy of dmesg. As soon as the monitor is turned off by the system the crash happens: [ 2674.166451] general protection fault: 0000 [#1] SMP NOPTI ... [ 2674.166530] RIP: 0010:dce110_vblank_set+0x4f/0xa0 [amdgpu] with the last 5 entries of the call trace: [ 2674.166624] dal_irq_service_set+0x4c/0x90 [amdgpu] [ 2674.166687] dc_interrupt_set+0x24/0x30 [amdgpu] [ 2674.166753] dm_enable_vblank+0x2a/0x40 [amdgpu] [ 2674.166768] drm_vblank_enable+0xe2/0x130 [drm] [ 2674.166781] drm_vblank_get+0x92/0xb0 [drm] I was using the Oibaf PPA both before and after I updated to Xubuntu 19.04. I tried to use the kernel v5.1-rc7 from the Ubuntu mainline: https://kernel.ubuntu.com/~kernel-ppa/mainline/ My linux command line: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1" -- You are receiving this mail because: You are the assignee for the bug.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019