amd issueshttps://gitlab.freedesktop.org/drm/amd/-/issues2023-05-25T05:59:51Zhttps://gitlab.freedesktop.org/drm/amd/-/issues/587Firefox smooth scrolling isn't smooth2023-05-25T05:59:51ZBugzilla Migration UserFirefox smooth scrolling isn't smooth## Submitted by sun..@..ail.ru
Assigned to **Default DRI bug account**
**[Link to original bug (#89374)](https://bugs.freedesktop.org/show_bug.cgi?id=89374)**
## Description
Kubuntu 14.04 x64, HD5770<br>
<br>
glxinfo |grep Open<br...## Submitted by sun..@..ail.ru
Assigned to **Default DRI bug account**
**[Link to original bug (#89374)](https://bugs.freedesktop.org/show_bug.cgi?id=89374)**
## Description
Kubuntu 14.04 x64, HD5770<br>
<br>
glxinfo |grep Open<br>
OpenGL vendor string: X.Org<br>
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER<br>
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2<br>
OpenGL core profile shading language version string: 3.30<br>
OpenGL core profile context flags: (none)<br>
OpenGL core profile profile mask: core profile<br>
OpenGL core profile extensions:<br>
OpenGL version string: 3.0 Mesa 10.3.2<br>
OpenGL shading language version string: 1.30<br>
OpenGL context flags: (none)<br>
<br>
Firefox has an option of smooth scrolling(Preferences -> General -> Use smooth scrolling). However it doesn't work on OSS drivers for my card. It does work on Intel ones and closed source though.https://gitlab.freedesktop.org/drm/amd/-/issues/313FireGL Mobility T2: WebGL under firefox16 freezes system2019-11-19T16:37:12ZBugzilla Migration UserFireGL Mobility T2: WebGL under firefox16 freezes system## Submitted by mir..@..sin.de
Assigned to **Default DRI bug account**
**[Link to original bug (#56878)](https://bugs.freedesktop.org/show_bug.cgi?id=56878)**
## Description
Created attachment 69702<br>
kernel messages of the cras...## Submitted by mir..@..sin.de
Assigned to **Default DRI bug account**
**[Link to original bug (#56878)](https://bugs.freedesktop.org/show_bug.cgi?id=56878)**
## Description
Created attachment 69702<br>
kernel messages of the crash<br>
<br>
When opening http://lwn.net/Articles/522127/ with firefox16 the screen goes black for a moment and then reappears for a few seconds after which it goes black again. This cycle goes on a few times after which the system completely locks up (even Magic Sysrq seems to have no effect).<br>
<br>
I don't know if it is related but sometimes opening huge images in firefox causes X to crash, too. This, however, doesn't freeze the kernel and beside the crash itself everything works normally afterwards.<br>
<br>
kernel: 3.6.6<br>
xorg-server: 1.13.0<br>
xf86-video-ati: 7.0.0<br>
mesa: 9.0<br>
<br>
**Attachment 69702**, "kernel messages of the crash": <br>
[kernel-log](/uploads/671e609a2ce735e6ec5d7376021e29b1/kernel-log)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/849FirePro v8800 Failure to recognize DisplayPort signal2023-05-25T05:23:03ZBugzilla Migration UserFirePro v8800 Failure to recognize DisplayPort signal## Submitted by François Jacques
Assigned to **Default DRI bug account**
**[Link to original bug (#106191)](https://bugs.freedesktop.org/show_bug.cgi?id=106191)**
## Description
Created attachment 139004<br>
callstack from DRM/rad...## Submitted by François Jacques
Assigned to **Default DRI bug account**
**[Link to original bug (#106191)](https://bugs.freedesktop.org/show_bug.cgi?id=106191)**
## Description
Created attachment 139004<br>
callstack from DRM/radeon<br>
<br>
DRM/radeon fails with in drm_dp_link_rate_to_bw_code <br>
<br>
Driver fails to negotiate video resolution with DP-connected monitor, on any of 4 DP ports. <br>
Controller can drive monitor at 2048x1080 through HDMI adapter. Straight DP cable only works in console (low-res)<br>
<br>
Disconnecting power cable from monitor for 5 minutes trick doesn't help ;)<br>
<br>
Video controller: FirePro v8800 ChipID 0x6888 (see hardware.txt for details, 4 DPs)<br>
DP monitor: Dell U2717DA <br>
Workstation: HP xw8600<br>
Kernel messages with backtrace: see var_log_messages_excerpt.txt<br>
Max res supported by monitor: 1440p (see Xorg.0.log)<br>
<br>
**Attachment 139004**, "callstack from DRM/radeon": <br>
[var_log_messages_excerpt.txt](/uploads/7510a27a2e4241d360530263a10e7a13/var_log_messages_excerpt.txt)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/208Flicker after waking from DPMS sleep2019-11-19T16:28:15ZBugzilla Migration UserFlicker after waking from DPMS sleep## Submitted by Lauri Kasanen `@cand`
Assigned to **Default DRI bug account**
**[Link to original bug (#39953)](https://bugs.freedesktop.org/show_bug.cgi?id=39953)**
## Description
Created attachment 50058<br>
lspci -vvnn<br>
<br>...## Submitted by Lauri Kasanen `@cand`
Assigned to **Default DRI bug account**
**[Link to original bug (#39953)](https://bugs.freedesktop.org/show_bug.cgi?id=39953)**
## Description
Created attachment 50058<br>
lspci -vvnn<br>
<br>
My E-350 laptop screen flickers for ~5 minutes every time after waking from DPMS. The flicker persists through VT switches and changing the power profile to high.<br>
<br>
After the wait it stabilizes and picture is good again.<br>
<br>
It looks similar to a CRT on 60Hz, but xrandr is confident the mode is right for the lcd (60hz, not something lower).<br>
<br>
<br>
Lenovo G575 laptop<br>
AMD E-350<br>
Linux 3.0.1<br>
<br>
**Attachment 50058**, "lspci -vvnn": <br>
[lspci.txt](/uploads/b2463a4191a68cb58be443642400cf7f/lspci.txt)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/786'flip queue failed in radeon_scanout_flip: Invalid argument' error and small ...2023-05-25T05:35:07ZBugzilla Migration User'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor## Submitted by Ome..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#100289)](https://bugs.freedesktop.org/show_bug.cgi?id=100289)**
## Description
Created attachment 130326<br>
Xorg log<br>
<br>
I have...## Submitted by Ome..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#100289)](https://bugs.freedesktop.org/show_bug.cgi?id=100289)**
## Description
Created attachment 130326<br>
Xorg log<br>
<br>
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.<br>
<br>
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...).<br>
<br>
Looking into Xorg.0.log, when I turn the monitor off for less than 10 seconds, I just get the following event:<br>
<br>
===============================================================================<br>
<br>
[ 512.737] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument<br>
<br>
===============================================================================<br>
<br>
Being off for 10 seconds or more results in:<br>
<br>
===============================================================================<br>
<br>
[ 1891.671] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840<br>
[ 1891.677] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy<br>
[ 1891.678] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy<br>
<br>
===============================================================================<br>
<br>
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:<br>
<br>
===============================================================================<br>
<br>
[ 2001.120] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760<br>
<br>
===============================================================================<br>
<br>
I have attached the X log.<br>
<br>
I'm currently running Devuan Testing (based off Debian Testing)<br>
uname -a: Linux omega1 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux<br>
X: 1.19.2-1<br>
radeon: 7.8.0<br>
<br>
Thanks for any help.<br>
<br>
**Attachment 130326**, "Xorg log": <br>
[Xorg.0.log](/uploads/b15b2dc5c7ab608e743e91ece2802949/Xorg.0.log)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/559Fragment shader value lock up rv635 device2023-05-25T06:00:05ZBugzilla Migration UserFragment shader value lock up rv635 device## Submitted by pav..@..ky.com
Assigned to **Default DRI bug account**
**[Link to original bug (#87126)](https://bugs.freedesktop.org/show_bug.cgi?id=87126)**
## Description
Created attachment 110596<br>
apitrace<br>
<br>
Changing...## Submitted by pav..@..ky.com
Assigned to **Default DRI bug account**
**[Link to original bug (#87126)](https://bugs.freedesktop.org/show_bug.cgi?id=87126)**
## Description
Created attachment 110596<br>
apitrace<br>
<br>
Changing output variable from vec4(1.0) to vec4(0.9) locks the gpu.<br>
<br>
**Attachment 110596**, "apitrace": <br>
[a.out.3.trace](/uploads/c47d9a0917f23c2341b52d445860012e/a.out.3.trace)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/770Full aspect scaling introduces interlacing on specific resolutions2023-05-25T05:45:15ZBugzilla Migration UserFull aspect scaling introduces interlacing on specific resolutions## Submitted by Platin
Assigned to **Default DRI bug account**
**[Link to original bug (#99368)](https://bugs.freedesktop.org/show_bug.cgi?id=99368)**
## Description
Created attachment 128897<br>
dmesg log<br>
<br>
When using full...## Submitted by Platin
Assigned to **Default DRI bug account**
**[Link to original bug (#99368)](https://bugs.freedesktop.org/show_bug.cgi?id=99368)**
## Description
Created attachment 128897<br>
dmesg log<br>
<br>
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.<br>
<br>
This happens only on some of the supported resolutions of the integrated display, those being 1280x720 and 1152x768.<br>
<br>
**Attachment 128897**, "dmesg log": <br>
[dmesg](/uploads/4ea56c1c8b75ddea20e6ea03bc5f1528/dmesg)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/501glamor with dual radeon segfaults2023-05-25T06:03:03ZBugzilla Migration Userglamor with dual radeon segfaults## Submitted by Philipp Schmitt
Assigned to **Default DRI bug account**
**[Link to original bug (#79564)](https://bugs.freedesktop.org/show_bug.cgi?id=79564)**
## Description
Created attachment 100332<br>
Xorg.0.log<br>
<br>
Hello...## Submitted by Philipp Schmitt
Assigned to **Default DRI bug account**
**[Link to original bug (#79564)](https://bugs.freedesktop.org/show_bug.cgi?id=79564)**
## Description
Created attachment 100332<br>
Xorg.0.log<br>
<br>
Hello,<br>
<br>
OS: ArchLinux<br>
Xorg: 1.15<br>
xf86-video-ati: 7.3.0<br>
xorg.conf: None<br>
<br>
I have two ATI 7750s. When only one card is present, startx works as expected <br>
but when both GPUs are plugged in, it results in a segfault (see attachment).<br>
Reverting to EXA works though.<br>
<br>
Thanks.<br>
<br>
**Attachment 100332**, "Xorg.0.log": <br>
[Xorg.0.log](/uploads/119be9e5f65ee4df6180f9b493a86667/Xorg.0.log)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/453Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/34702023-05-25T06:05:12ZBugzilla Migration UserGlitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470## Submitted by tde..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#75649)](https://bugs.freedesktop.org/show_bug.cgi?id=75649)**
## Description
Screen flickering and horizontal black/white lines mixed...## Submitted by tde..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#75649)](https://bugs.freedesktop.org/show_bug.cgi?id=75649)**
## Description
Screen flickering and horizontal black/white lines mixed in with output on redraw. This only happens when using HDMI output to a single external 1920x1080 monitor and not when using dual monitors or the single laptop screen. If the screen is static or I move the mouse over a single color background, no glitching happens. It seems that the more that needs to get redrawn in the frame, the worse it gets.<br>
<br>
I'm not sure how long this has been a problem because I rarely use a single monitor. I'll report back when mesa 10.1 is released on Arch.<br>
<br>
System info from Phoronix Test Suite:<br>
Hardware:<br>
Processor: Intel Core 2 Duo P8400 @ 2.27GHz (2 Cores), Motherboard: Sony VAIO, Chipset: Intel Mobile 4 MCH + ICH9M, Memory: 3072MB, Disk: 320GB Western Digital WD3200BEKT-7, Graphics: AMD Mobility Radeon HD 3450/3470 256MB (680/800MHz), Audio: Realtek ALC262, Monitor: DELL ST2220L, Network: Marvell 88E8055 PCI-E Gigabit + Qualcomm Atheros AR928X Wireless<br>
<br>
Software:<br>
OS: Linux, Kernel: 3.13.5-1-ARCH (x86_64), Desktop: Cinnamon 2.0.14, Display Server: X Server 1.15.0, Display Driver: radeon 7.3.0, OpenGL: 3.1 Mesa 10.0.3 Gallium 0.4, Compiler: GCC 4.8.2 20140206 + Clang 3.4 + LLVM 3.4, File-System: ext4, Screen Resolution: 1920x1080https://gitlab.freedesktop.org/drm/amd/-/issues/800gnome-shell crashes when opening laptop lid2023-05-25T05:33:04ZBugzilla Migration Usergnome-shell crashes when opening laptop lid## Submitted by d.v..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#101146)](https://bugs.freedesktop.org/show_bug.cgi?id=101146)**
## Description
I made this bug (https://bugzilla.gnome.org/show_bug.c...## Submitted by d.v..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#101146)](https://bugs.freedesktop.org/show_bug.cgi?id=101146)**
## Description
I made this bug (https://bugzilla.gnome.org/show_bug.cgi?id=782929) on gnome-shell, but was told it's a radeon bug so I thought I'd let you know.<br>
<br>
Original text:<br>
Sometimes when I open my laptop I am greeted with the screen as shown in the attachment. This does not happen every time.<br>
<br>
Sometimes it stays on that screen and I can't do anything. Other times I can see a blacks screen with text, similar to the picture, flash and it shows the login screen. When I click on my user, enter my password and press enter I am greeted with the login screen again. Because it only flashes by, I am unsure if it's the same output.<br>
<br>
Also sometimes when I login the mouse is very slow/laggy. I'm not sure if it's related, but I thought I'd mention it anyway. No black screen with text flashes before the login screen in this case though.<br>
<br>
I typed out some parts of the error message in case it was useful: https://izumi.tv/f/gshell.txt<br>
<br>
If any other information is require, let me know what and how I can find it.<br>
<br>
This is the error message on the screen: https://izumi.tv/i/mutter.jpg<br>
<br>
Additional info I think may be useful:<br>
GPU: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Chelsea XT GL [FirePro M4000]<br>
OS: Korora 25 (basically Fedora 25)<br>
Kernel version: 4.10.15-200.fc25.x86_64<br>
Crash log: https://izumi.tv/f/crashstuff.txt<br>
<br>
The error message in the gnome-shell bug report seems relevant and can be found in crashstuff.txthttps://gitlab.freedesktop.org/drm/amd/-/issues/606GPU card fans run full speed at all times2023-05-25T05:57:56ZBugzilla Migration UserGPU card fans run full speed at all times## Submitted by Todd
Assigned to **Default DRI bug account**
**[Link to original bug (#90263)](https://bugs.freedesktop.org/show_bug.cgi?id=90263)**
## Description
Arch w/ Linux 4. AMD "6770" "BARTS" GPU.<br>
<br>
GPU fans run at ...## Submitted by Todd
Assigned to **Default DRI bug account**
**[Link to original bug (#90263)](https://bugs.freedesktop.org/show_bug.cgi?id=90263)**
## Description
Arch w/ Linux 4. AMD "6770" "BARTS" GPU.<br>
<br>
GPU fans run at full speed at all times.<br>
<br>
Lots of promises on the forums that the fix would "just work" in Linux 4. It did not.<br>
<br>
Not an issue when dual-booted to Windows 7. Fans run properly.https://gitlab.freedesktop.org/drm/amd/-/issues/539GPU faults with Xonotic 0.72023-05-25T06:01:54ZBugzilla Migration UserGPU faults with Xonotic 0.7## Submitted by darkbasic
Assigned to **Default DRI bug account**
**[Link to original bug (#84106)](https://bugs.freedesktop.org/show_bug.cgi?id=84106)**
## Description
Created attachment 106566<br>
dmesg<br>
<br>
I have an HD 795...## Submitted by darkbasic
Assigned to **Default DRI bug account**
**[Link to original bug (#84106)](https://bugs.freedesktop.org/show_bug.cgi?id=84106)**
## Description
Created attachment 106566<br>
dmesg<br>
<br>
I have an HD 7950 with latest graphic stack from git, including LLVM 3.6 git from today. kernel is drm-next-3.18-wip from today (3.17.0-rc5-drm-next-3.18-wip).<br>
I was running some benchmarks (http://openbenchmarking.org/result/1409197-SO-1407298SO78) while I noticed sometimes the picture froze and then after a second or two it kept running the benchmark ultra fast. when the benchmark finished I noticed lots of GPU faults in dmesg: https://paste.lugons.org/show/5981/<br>
<br>
**Attachment 106566**, "dmesg": <br>
[dmesg](/uploads/3f11fa247a5cbf20f2da57cf26f5c52c/dmesg)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/593GPU lockup and kernel OOPS when using PRIME2023-05-25T05:58:05ZBugzilla Migration UserGPU lockup and kernel OOPS when using PRIME## Submitted by Rafael Ristovski
Assigned to **Default DRI bug account**
**[Link to original bug (#89536)](https://bugs.freedesktop.org/show_bug.cgi?id=89536)**
## Description
Created attachment 114225<br>
Two of the kernel hangs,...## Submitted by Rafael Ristovski
Assigned to **Default DRI bug account**
**[Link to original bug (#89536)](https://bugs.freedesktop.org/show_bug.cgi?id=89536)**
## Description
Created attachment 114225<br>
Two of the kernel hangs, note one is an OOPS, while the other is not, I was able to shut down the machine normally after the first OOPS as the kernel was still responsive to power button events.<br>
<br>
When running OpenGL applications with PRIME, the screen freezes and a kernel OOPS is generated. This seems to happen either when the application starts, or the window of the application is re-drawn (moving workspaces, minimizing/maximizing) Crashes seem to be inconsistent as sometimes the kernel just freezes and no OOPS is generated.<br>
<br>
OS Details:<br>
Archlinux with kernel 3.19.1-1<br>
xorg-server 1.17.1-3<br>
xf86-video-intel 2.99.917-4<br>
xf86-video-ati 1:7.5.0-2<br>
libdrm 2.4.59-1<br>
<br>
Below is an attached kernel log with _TWO_ separate kernel hang, both caused by running an OpenGL application with PRIME.<br>
<br>
**Attachment 114225**, "Two of the kernel hangs, note one is an OOPS, while the other is not, I was able to shut down the machine normally after the first OOPS as the kernel was still responsive to power button events.": <br>
[file_89536.txt](/uploads/4930b785e91783923890dae007d36be4/file_89536.txt)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/694GPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (...2023-05-25T05:52:10ZBugzilla Migration UserGPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (works fine with fglrx)## Submitted by Azari
Assigned to **Default DRI bug account**
**[Link to original bug (#93895)](https://bugs.freedesktop.org/show_bug.cgi?id=93895)**
## Description
I've had this lockup on this machine for the past few years, acro...## Submitted by Azari
Assigned to **Default DRI bug account**
**[Link to original bug (#93895)](https://bugs.freedesktop.org/show_bug.cgi?id=93895)**
## Description
I've had this lockup on this machine for the past few years, across several different kernel versions, different distributions, etc. Booting with KMS works fine, but the second a graphical environment starts (whether X or wayland-based), it locks up.<br>
<br>
Booting Ubuntu with user-space mode-setting works, and then I can install FGLRX from there and everything works fine. After speaking with airlied on IRC, they suggested it could be a workaround that AMD has put into FGLRX that never made it into the opensource drivers, and that AMD might have to look into it.<br>
<br>
CPU/GPU : A4-3400<br>
Motherboard : GA-A75M-D2H ( http://www.gigabyte.com/products/product-page.aspx?pid=3930#ov )<br>
<br>
journalctl log of the lockup:<br>
<br>
------------------------------------------------------------<br>
<br>
Jan 27 18:28:32 miku dbus-daemon[374]: Successfully activated service 'org.freedesktop.systemd1'<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: ring 0 stalled for more than 10000msec<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 0)<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: Saved 55 dwords of commands on ring 0.<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU softreset: 0x00000009<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS = 0xB1403828<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0 = 0x28000007<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1 = 0x00000007<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS = 0x20000840<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS2 = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x40000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00008000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x80228643<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00D034_DMA_STATUS_REG = 0x44C83D57<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_SOFT_RESET=0x00007F6B<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_SOFT_RESET=0x00000100<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS = 0x00003828<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0 = 0x00000007<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1 = 0x00000007<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS = 0x20000040<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS2 = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x00000000<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00D034_DMA_STATUS_REG = 0x44C83D57<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU reset succeeded, trying to resume<br>
Jan 27 18:28:42 miku kernel: [drm] Found smc ucode version: 0x00011100<br>
Jan 27 18:28:42 miku kernel: [drm] PCIE GART of 1024M enabled (table at 0x0000000000274000).<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: WB enabled<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8800c613fc00<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff8800c613fc0c<br>
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc90002432118<br>
Jan 27 18:28:42 miku kernel: [drm] ring test on 0 succeeded in 1 usecs<br>
Jan 27 18:28:42 miku kernel: [drm] ring test on 3 succeeded in 3 usecs<br>
Jan 27 18:28:42 miku kernel: [drm] ring test on 5 succeeded in 1 usecs<br>
Jan 27 18:28:42 miku kernel: [drm] UVD initialized successfully.<br>
Jan 27 18:28:52 miku kernel: radeon 0000:00:01.0: ring 0 stalled for more than 10370msec<br>
Jan 27 18:28:52 miku kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x0000000000000002 last fence id 0x0000000000000004 on ring 0)<br>
Jan 27 18:28:52 miku kernel: [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35).<br>
Jan 27 18:28:52 miku kernel: [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35).<br>
Jan 27 18:29:22 miku systemd[1]: Started Getty on tty2.<br>
<br>
------------------------------------------------------------https://gitlab.freedesktop.org/drm/amd/-/issues/209GPU lockup (waiting for 0x0002F05C last fence id 0x0002F05A), oops in radeon_...2019-11-19T16:28:32ZBugzilla Migration UserGPU lockup (waiting for 0x0002F05C last fence id 0x0002F05A), oops in radeon_ring_write, and screen turns off## Submitted by Volodymyr Shcherbyna
Assigned to **Default DRI bug account**
**[Link to original bug (#40128)](https://bugs.freedesktop.org/show_bug.cgi?id=40128)**
## Description
Created attachment 50258<br>
dmesg output describi...## Submitted by Volodymyr Shcherbyna
Assigned to **Default DRI bug account**
**[Link to original bug (#40128)](https://bugs.freedesktop.org/show_bug.cgi?id=40128)**
## Description
Created attachment 50258<br>
dmesg output describing original problem<br>
<br>
Hello,<br>
<br>
I have HD 3600 and I am using Debian sid x86_64. I have noticed recently in my dmesg output the following line: "failed to evaluate ATIF got AE_BAD_PARAMETER" and I was suggested to file a bug here.<br>
<br>
Please see attached full dmesg output of my machine.<br>
<br>
Thank you,<br>
<br>
V.<br>
<br>
**Attachment 50258**, "dmesg output describing original problem": <br>
[hd3600_problem.txt](/uploads/169b16af85c6e3f62eacfb775090e1c3/hd3600_problem.txt)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/52graphics corruption after resume with radeon and with KDE 4 with compositing ...2020-10-06T00:09:38ZBugzilla Migration Usergraphics corruption after resume with radeon and with KDE 4 with compositing enabled## Submitted by Martin Steigerwald
Assigned to **Default DRI bug account**
**[Link to original bug (#22621)](https://bugs.freedesktop.org/show_bug.cgi?id=22621)**
## Description
Created attachment 27387<br>
X.org configuration fil...## Submitted by Martin Steigerwald
Assigned to **Default DRI bug account**
**[Link to original bug (#22621)](https://bugs.freedesktop.org/show_bug.cgi?id=22621)**
## Description
Created attachment 27387<br>
X.org configuration file<br>
<br>
After resume from suspend to ram or suspend to disk using TuxOnIce there is graphics garbage around window borders. It goes away when I start systemsettings, untick the checkmark for activating desktop effect, tick it again and press "Apply". It also goes away when I disable compositing and re-enable it again afterwards. I did not see other malfunctions, just the graphics corruption while compositing is still working after resume.<br>
<br>
I don't know whether DRI is the approbiate place to report this against. I do not even know whether it might be a KDE 4 kwin problem instead. But I had to start somewhere.<br>
<br>
This is happening on an IBM ThinkPad T42 with radeon chipset:<br>
martin@shambhala:~> lspci -nn | grep VGA<br>
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50]<br>
<br>
Using XOrg CVS as 7.4 is not in the version list. I use the following on a mixture of Debian Lenny/Squeeze/Sid/Experimental:<br>
<br>
martin@shambhala:~> apt-show-versions | egrep "(libgl1-mesa-dri|xserver-xorg-video-radeon|xserver-xorg/|xserver-xorg-core/)"<br>
libgl1-mesa-dri/sid uptodate 7.4.4-1<br>
xserver-xorg/sid uptodate 1:7.4+3<br>
xserver-xorg-core/sid uptodate 2:1.6.1.901-3<br>
xserver-xorg-video-radeon/sid uptodate 1:6.12.2-2<br>
xserver-xorg-video-radeonhd/sid uptodate 1.2.5-1<br>
<br>
(I made sure that X.org and Mesa related packages are consistently at Sid.)<br>
<br>
I am using radeon driver.<br>
<br>
I attach my xorg.conf. I also attach two screenshots that demonstrate the problem.<br>
<br>
Regarding my xorg.conf: I am using XAA, since X.org tends to use 99% CPU with EXA. Yes, I know glxgears is not a benchmark. I am using CONFIG_FB_RADEON.<br>
<br>
My current kernel is:<br>
<br>
martin@shambhala:~> cat /proc/version<br>
Linux version 2.6.29.2-tp42-toi-3.0.1 (martin@shambhala) (gcc version 4.3.3 (Debian 4.3.3-3) ) #2 PREEMPT Tue Apr 28 22:08:44 CEST 2009<br>
<br>
I do not yet use 2.6.30 since it reboots after resuming from TuxOnIce hibernation. I am building a new kernel with 2.6.30.1 and some TuxOnIce fixes that might work tough. I will report when it works and it makes any difference.<br>
<br>
Please tell me when you need anything more.<br>
<br>
**Attachment 27387**, "X.org configuration file": <br>
[xorg.conf](/uploads/57ad744ec1986977245f4cfd16318f8d/xorg.conf)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/741Hang on resume [AMD/ATI] RV515/M54 [Mobility Radeon X1400]2023-05-25T05:48:12ZBugzilla Migration UserHang on resume [AMD/ATI] RV515/M54 [Mobility Radeon X1400]## Submitted by Nikolay
Assigned to **Default DRI bug account**
**[Link to original bug (#97838)](https://bugs.freedesktop.org/show_bug.cgi?id=97838)**
## Description
I've got Dell Inspiron 6400 with Ubuntu 16.04, oibaf drivers an...## Submitted by Nikolay
Assigned to **Default DRI bug account**
**[Link to original bug (#97838)](https://bugs.freedesktop.org/show_bug.cgi?id=97838)**
## Description
I've got Dell Inspiron 6400 with Ubuntu 16.04, oibaf drivers and kernel 4.7.3.<br>
<br>
The box doesn't seem to be able to come out of STR - it just hangs with black screen.<br>
<br>
I've tried 'echo devices > /sys/power/pm_test; echo mem > /sys/power/state' and on resume I often get to see my desktop but then box completely freezes - no keyboard, no mouse, no net.<br>
<br>
I've tried suspending/resumeing in console mode and could not reproduce this problem.<br>
<br>
On previous Ubuntu kernels (stock) it hangs often, but sometimes it is able to resume, in 4.7.3 it seems to be handging close to 100% percent of the time.<br>
<br>
Unfortunately I'm not really able to get any debug logs since box gets totally frozen. Is there any way I can provide any more information or debug this?<br>
<br>
Thanks!https://gitlab.freedesktop.org/drm/amd/-/issues/784Hang regression with R7 M370, identified possible culprit commit2023-05-25T05:44:36ZBugzilla Migration UserHang regression with R7 M370, identified possible culprit commit## Submitted by Mauro Santos
Assigned to **Default DRI bug account**
**[Link to original bug (#100222)](https://bugs.freedesktop.org/show_bug.cgi?id=100222)**
## Description
Created attachment 130246<br>
lspci -nnk and dmesg outpu...## Submitted by Mauro Santos
Assigned to **Default DRI bug account**
**[Link to original bug (#100222)](https://bugs.freedesktop.org/show_bug.cgi?id=100222)**
## Description
Created attachment 130246<br>
lspci -nnk and dmesg output<br>
<br>
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).<br>
<br>
When running any demanding application with DRI_PRIME=1 the card will hang, one example would be running 'DRI_PRIME=1 glmark2 -b texture'.<br>
<br>
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.<br>
<br>
With 4.9:<br>
power level 4 sclk: 75000 mclk: 80000 vddc: 1050 vddci: 0 pcie gen: 2<br>
<br>
With 4.10:<br>
power level 4 sclk: 87500 mclk: 90000 vddc: 1050 vddci: 0 pcie gen: 2<br>
<br>
This led me to revert commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 which prevents the card from hanging.<br>
<br>
You can find the output of lspci and dmesg in the attachment for the case with commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 reverted.<br>
<br>
**Attachment 130246**, "lspci -nnk and dmesg output": <br>
[lspci_dmesg.tar.gz](/uploads/4145d0d5776a8fbd782a8647dfe0f36a/lspci_dmesg.tar.gz)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/640Hard lock after running built-in radeon.ko tests (Linux kernel 4.2.0)2023-05-25T05:55:07ZBugzilla Migration UserHard lock after running built-in radeon.ko tests (Linux kernel 4.2.0)## Submitted by iive
Assigned to **Default DRI bug account**
**[Link to original bug (#91961)](https://bugs.freedesktop.org/show_bug.cgi?id=91961)**
## Description
Created attachment 118192<br>
Kernel logs from running both test a...## Submitted by iive
Assigned to **Default DRI bug account**
**[Link to original bug (#91961)](https://bugs.freedesktop.org/show_bug.cgi?id=91961)**
## Description
Created attachment 118192<br>
Kernel logs from running both test at the same time and from running the second test only..<br>
<br>
Built-in tests are enabled by the module "option radeon test=3". The integer value bits are used as flags what test to run on the module load.<br>
<br>
Running both test takes about 1-2 minutes to complete. The first one turns off the display and trashes the system in a way that the first key pressed hangs it hard - no flashing LEDs, no Magic SysRq.<br>
<br>
---<br>
The first test moves data from system ram to video ram and back.<br>
It runs for about a minute. During that time the monitor is turning off and on again (DELLs do that if DPMS signaling is not exactly right, its on DVI port). The rest of the system seems to function. Boot loading seams to finish and sometimes I can salvage complete kernel message log. Pressing CapsLock turns on its LED, but second press have no effect. Even pressing Magic SysRq first doesn't provide any control of the system. It hangs hard and only reset helps.<br>
<br>
The seconds test is about syncing between GPU rings.<br>
It seems to finish without error if run after the first one.<br>
However if I run it alone with "test=2", I get a bunch of timeouts, "GPU lockup" and other errors. When run alone the test doesn't prevent setting of working graphic mode.<br>
<br>
My videocard is Radeon HD5670 (Redwood).<br>
I have confirmation that the same happens on Tahiti chipsets.<br>
<br>
**Attachment 118192**, "Kernel logs from running both test at the same time and from running the second test only..": <br>
[radeon.test.hang.tgz](/uploads/d53c355e2b65dfa5827393fbcb3f01e6/radeon.test.hang.tgz)<br>https://gitlab.freedesktop.org/drm/amd/-/issues/790Hard lockup with radeonsi driver on FirePro W600, W9000 and W91002023-05-25T05:35:03ZBugzilla Migration UserHard lockup with radeonsi driver on FirePro W600, W9000 and W9100## Submitted by Julien Isorce `@cap`
Assigned to **Default DRI bug account**
**[Link to original bug (#100465)](https://bugs.freedesktop.org/show_bug.cgi?id=100465)**
## Description
Created attachment 130563<br>
dmesg<br>
<br>
The...## Submitted by Julien Isorce `@cap`
Assigned to **Default DRI bug account**
**[Link to original bug (#100465)](https://bugs.freedesktop.org/show_bug.cgi?id=100465)**
## Description
Created attachment 130563<br>
dmesg<br>
<br>
The machine completely freeze using radeonsi driver with FirePro W600, W9000 and W9100.<br>
<br>
* Steps to reproduce:<br>
<br>
wget http://www.phoronix-test-suite.com/benchmark-files/GpuTest_Linux_x64_0.7.0.zip<br>
DISPLAY=:0 ./GpuTest /test=fur /fullscreen<br>
<br>
* Acutal result:<br>
<br>
System and screen are frozen after a few minutes (sometimes a few seconds, sometimes 20 min). No mouse/keyboard. Does not respond to ping. No kernel panic. Requires hard reboot.<br>
<br>
After reboot, no error in /var/log/kern.log. Empty dir /var/crash, empty dir /sys/fs/pstore. Sometimes some nul characters ^@ just before the next "Linux version".<br>
Using a serial console does not show additional debug messages.<br>
<br>
* Expected result:<br>
<br>
No system freeze.<br>
<br>
* List of things that have been tried but leading to the same result:<br>
<br>
- kernel 4.4.X, 4.8.x packaged by ubuntu.<br>
- amd-staging-4.9 from https://cgit.freedesktop.org/~agd5f/linux.<br>
- a few 4.10 kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ .<br>
- radeon.dpm=1 (all values for power_dpm_state / power_dpm_force_performance_level)<br>
- radeon.dpm=0 (power_mode=profile and all values for power_profile)<br>
- radeon.msi=1 / 0.<br>
- DRI2 / DRI3<br>
- glamor / no accel, TearFree on / off<br>
- single monitor, multi monitor, resolutions 1600x1200, 1920x1080.<br>
- Latest libdrm / mesa. llvm 3.8, 4 and 5.<br>
<br>
* List of things that avoids the system freeze:<br>
<br>
- radeon.gartsize=512 radeon.vramlimit=1024<br>
<br>
* Others:<br>
<br>
- apitrace trace then replay does not lead to the freeze.<br>
- No errors with R600_DEBUG=* or MESA_DEBUG.<br>
- strace sometimes shows that the last call is ioctl(RADEON_CS) but not sure how reliable this is provinding the last print might not be flush.<br>
- Happens with 2 differents brand for the mother board.<br>
- takes a bit longer for the mentioned GpuTest to freeze the machine on W9000 and W9100.<br>
<br>
* TODOs:<br>
<br>
- Try again kgdb.<br>
- Try amdgpu instead of radeonsi.<br>
<br>
**Attachment 130563**, "dmesg": <br>
[dmesg.log](/uploads/1314c1ec8004b9bbd23c1299767f4aad/dmesg.log)<br>