dri-devel March 2017

dri-devel@lists.freedesktop.org

241 participants
1501 discussions

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100289 Bug ID: 100289 Summary: 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: OmegaPhil(a)startmail.com Created attachment 130326 --> https://bugs.freedesktop.org/attachment.cgi?id=130326&action=edit Xorg log I have just bought a 3rd monitor, successfully hooked up via Display Port to the R9 290X (Tahiti XT) card and configured fine as 3 non-mirrored outputs in XFCE4. I found that when I turned it off for ~10 seconds or more, after turning it back on all screens would go black and appear to reinialise. XFCE4 gets confused and clones the primary monitor output to the new 3rd screen, fiddling in the XFCE4 Display program fixes this (after the problem happens it seems to put the primary and new monitor on top of each other...). Looking into Xorg.0.log, when I turn the monitor off for less than 10 seconds, I just get the following event: =============================================================================== [ 512.737] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument =============================================================================== Being off for 10 seconds or more results in: =============================================================================== [ 1891.671] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840 [ 1891.677] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy [ 1891.678] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy =============================================================================== It now makes sense why monitor output appears to be mirrored (only 2 unique outputs) - 3840 is 1920*2. When I fix the configuration with XFCE4, the correct frame buffer is set up: =============================================================================== [ 2001.120] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760 =============================================================================== I have attached the X log. I'm currently running Devuan Testing (based off Debian Testing) uname -a: Linux omega1 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux X: 1.19.2-1 radeon: 7.8.0 Thanks for any help. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[Bug 100222] Hang regression with R7 M370, identified possible culprit commit
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100222 Bug ID: 100222 Summary: Hang regression with R7 M370, identified possible culprit commit Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: registo.mailling(a)gmail.com Created attachment 130246 --> https://bugs.freedesktop.org/attachment.cgi?id=130246&action=edit lspci -nnk and dmesg output After updating from kernel 4.9 series to 4.10 series I have identified a regression when using the discrete GPU on my laptop (Lenovo Thinkpad E560). When running any demanding application with DRI_PRIME=1 the card will hang, one example would be running 'DRI_PRIME=1 glmark2 -b texture'. I have noticed that the content of /sys/kernel/debug/dri/1/radeon_pm_info has changed between kernel 4.9 and 4.10 when running glmark2. With 4.9: power level 4 sclk: 75000 mclk: 80000 vddc: 1050 vddci: 0 pcie gen: 2 With 4.10: power level 4 sclk: 87500 mclk: 90000 vddc: 1050 vddci: 0 pcie gen: 2 This led me to revert commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 which prevents the card from hanging. You can find the output of lspci and dmesg in the attachment for the case with commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 reverted. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 99970] DRI3 steam login window is empty
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99970 Bug ID: 99970 Summary: DRI3 steam login window is empty Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: cosiekvfj(a)o2.pl Created attachment 129927 --> https://bugs.freedesktop.org/attachment.cgi?id=129927&action=edit screenshot Steam login window is empty with dri3. Window is functional. I can write my password and when I press enter I can login to steam. After that everything is normal. With dri2 bug is not present. 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M] -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 99881] Lockup/Freezes on Laptop with switchable graphics
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99881 Bug ID: 99881 Summary: Lockup/Freezes on Laptop with switchable graphics Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: matthew(a)tech3.me Created attachment 129781 --> https://bugs.freedesktop.org/attachment.cgi?id=129781&action=edit dmesg log Hi, I have a HP Pavilion dv6-3111sa laptop (circa 2010) with 2 GPUs: 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] [1002:9712] 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] [1002:68e0] (rev ff) I am running Ubuntu 16.04.2 with kernel Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 The screen usually freezes for a fraction of a second and then again a few seconds later. It may do this several times. In addition, the computer usually locks up before/after graphical login requiring a hard shutdown, although it doesn't always lock up. It seems to be preventing the computer from shutting down normally as well. This appears in dmesg output whenever a freeze occurs: 186.427140] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 186.431201] [drm] PCIE GART of 512M enabled (table at 0x000000000014C000). [ 186.431293] radeon 0000:02:00.0: WB enabled [ 186.431301] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff958c0f4f3c00 [ 186.431306] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff958c0f4f3c0c [ 186.431703] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffad3d81a1c418 [ 186.447926] [drm] ring test on 0 succeeded in 1 usecs [ 186.447934] [drm] ring test on 3 succeeded in 2 usecs [ 186.634582] [drm] ring test on 5 succeeded in 1 usecs [ 186.634592] [drm] UVD initialized successfully. [ 186.634648] [drm] ib test on ring 0 succeeded in 0 usecs [ 186.634686] [drm] ib test on ring 3 succeeded in 0 usecs [ 186.805724] [drm] ib test on ring 5 succeeded [ 186.838322] snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo [ 186.942052] snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535 [ 196.033454] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo [ 196.646111] snd_hda_intel 0000:02:00.1: Cannot lock devices! Adding radeon.runpm=0 to my boot cmdline solves the issues as a workaround. With previous ubuntu/kernel versions, the main issue was the freezing which would happen every seven seconds with the corresponding dmesg block. This would continue ad infinitum, although on rare occasions it would stop after many freezes. However with my current kernel this pattern doesn't seem to occur - it freezes a few times before the freezing stops and the freezes do not occur at regular intervals. I'm not sure if this is a graphics or sound issue from the dmesg block. There's also some ACPI errors in the dmesg log so maybe a firmware problem, or faulty hardware? I tried some lower level debugging previously but couldn't conclude anything. Thanks for any assistance. -- You are receiving this mail because: You are the assignee for the bug.

1 36

[Bug 99679] DRI PRIME doesn't always work with intel/radeon
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99679 Bug ID: 99679 Summary: DRI PRIME doesn't always work with intel/radeon Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: lev258(a)freemail.hu Hello. I am running Ubuntu 16.04, with MATE installed later on it, using the latter currently. Beside normal system updates, I am using the Mesa stable ppa. Recently I started using DRI_PRIME=1 in some cases, to make the AMD videocard working. I found that it doesn't always work and the Intel one is used instead, like DRI_PRIME didn't even matter to it. This happens with Unigine Heaven, Steam and even glxinfo. Strangely, glxgears is not affected, it always does what it should be. I cannot reproduce this behaviour, it just happens sometimes. And it seems to solve itself after a reboot. Tell me, what you need to look into it. Thanks. 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus PRO [Radeon HD 8850M / R9 M265X] (rev ff) -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99368 Bug ID: 99368 Summary: Full aspect scaling introduces interlacing on specific resolutions Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: gamwizh00(a)gmail.com Created attachment 128897 --> https://bugs.freedesktop.org/attachment.cgi?id=128897&action=edit dmesg log When using full aspect scaling in xrandr on a laptop with an A6-6310 apu the display is showing interlaced lines across the whole display. This happens only on some of the supported resolutions of the integrated display, those being 1280x720 and 1152x768. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 99326] Boot problem and White dots/noise/speckling/shimmering/corruption on Radeon HD6320
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99326 Bug ID: 99326 Summary: Boot problem and White dots/noise/speckling/shimmering/corruption on Radeon HD6320 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: mrj(a)advancedcontrols.com.au A default Gnome install of either Fedora 25 or Fedora 24 (latest spin) Workstation, on a machine with a Radeon HD6320 (AMD G-series T56N) graphics chip running 1360x768@60Hz, has a display that most of the time is black on boot (reboot required -- hangs?), but occasionally completes booting with a display that all over shimmers with white noise, as seen in the following video: https://www.youtube.com/watch?v=dHW6kM4koQ0 The problem has been traced to this Linux kernel commit https://github.com/torvalds/linux/commit/ff0bd441bdfbfa09d05fdba9829a0401a4… , made to fix Bug 95206. Xorg logs and xrandr output seem to indicate the the same modeline is selected after this commit is reversed, even though the boot and display problems no longer occur. The equivalent Red Hat bug is https://bugzilla.redhat.com/show_bug.cgi?id=1402293 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 99316] Radeon crash when laptop on AC power
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99316 Bug ID: 99316 Summary: Radeon crash when laptop on AC power Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: LordSamanon(a)gmail.com Created attachment 128807 --> https://bugs.freedesktop.org/attachment.cgi?id=128807&action=edit AC Power Unigine Heaven dmesg I have a Dell laptop with an Intel iGPU and a Radeon dGPU (a Firepro W5130M, recognized as a Radeon HD 8830M by lspci). Whenever I attempt to use the Radeon card via DRI_PRIME=1 while the laptop is plugged in, the card crashes. When on battery the card performs fine. One way I have tested this is with glxgears. Often glxgears will work the first time it is run, but if it is closed and then opened a few seconds later, it will crash. I have also tried running programs like Portal 2 and Unigine Heaven. These always hang. Unfortunately the error messages produced in dmesg are not the most consistent. Sometimes I get a backtrace, sometimes even a kernel panic on reboot. I'll post the various logs I have. One thing I have found is that glxgears does not crash if I use radeon.runpm=0, however it still hangs when running something like Portal. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 99181] RS780 blank screen on boot
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99181 Bug ID: 99181 Summary: RS780 blank screen on boot Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: chithanh(a)gentoo.org Hardware: BIOSTAR A780L When booting with 3.15 or newer kernels, a monitor connected to the DVI port of the BIOSTAR A780L will stay blank. Kernel 3.14 and older work fine. I tried forcing the output to on with video=HDMI-A-1:e but this made no difference. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 99049] Machine freeze when clock are set to defaults
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99049 Bug ID: 99049 Summary: Machine freeze when clock are set to defaults Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: ls(a)maxux.net My laptop contains theses cards: ---- 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330] (rev 81) ---- Under Gentoo, I enabled radeon and radeonsi as videos cards, everything looks fine. According to xrandr, I have providers: ---- Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:Intel Provider 1: id: 0x4f cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 0 name:HAINAN @ pci:0000:01:00.0 ---- I found on the internet that DPM could cause issue, I tried: radeon.runpm=0 radeon.dpm=0 (see below) Using theses settings, I don't have any freeze when I try to use the Radeon Card (using DRI_PRIME=1), but I found that everything was slow. I checked, and I saw: --- cat /sys/class/drm/card1/device/power_method profile cat /sys/class/drm/card1/device/power_profile default cat /sys/kernel/debug/dri/65/radeon_pm_info default engine clock: 1070000 kHz current engine clock: 299990 kHz default memory clock: 900000 kHz current memory clock: 298990 kHz voltage: 1150 mV PCIE lanes: 4 --- The card is running in low profile by default, don't know why. Setting power_profile to high, mid or low doesn't change anything, but if I set power_profile back to default again, the clock is set to full speed. When clock is set to full speed, my system freeze if I try to run any 3D application (glxgears or a game using wine). Here is the dmesg log: --- radeon 0000:01:00.0: ring 0 stalled for more than 10436msec radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000014f4 last fence id 0x00000000000014f6 on ring 0) radeon 0000:01:00.0: Saved 49 dwords of commands on ring 0. radeon 0000:01:00.0: GPU softreset: 0x00000049 radeon 0000:01:00.0: GRBM_STATUS = 0xE5D04028 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0xEE400000 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000006 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00008000 radeon 0000:01:00.0: R_008680_CP_STAT = 0x80030243 radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 radeon 0000:01:00.0: GRBM_SOFT_RESET=0x0000DDFF radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000100 radeon 0000:01:00.0: GRBM_STATUS = 0x00003028 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000006 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000006 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: GPU reset succeeded, trying to resume [drm] probing gen 2 caps for device 8086:9d10 = 1724843/e [drm] PCIE gen 3 link speeds already enabled [drm] PCIE GART of 2048M enabled (table at 0x0000000000040000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000100000c00 and cpu addr 0xffff88046c66dc00 radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000100000c04 and cpu addr 0xffff88046c66dc04 radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000100000c08 and cpu addr 0xffff88046c66dc08 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000100000c0c and cpu addr 0xffff88046c66dc0c radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000100000c10 and cpu addr 0xffff88046c66dc10 [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [drm:si_resume [radeon]] *ERROR* si startup failed on resume --- I found out with theses steps that, if I don't set dpm=0, I hit exactly the same issue, I guess using DPM the clock is set to high when the card is used and it crash. When the card is stuck on that loop, I need to reset the machine (but network still works). I'm using mesa-13.0.2 with a 4.7.6 kernel, I have the same issue using mesa 12.0.1 -- You are receiving this mail because: You are the assignee for the bug.

1 4

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2017