| Bug ID | 111122 |
|---|---|
| Summary | 2500U: Graphics corruption on kernel 5.2 |
| Product | DRI |
| Version | XOrg git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | andreaskem@web.de |
Created attachment 144771 [det= ails] Kernel log Arch Linux Lenovo E485 (16 GiB RAM) AMD Ryzen 2500U xorg-server 1.20.5-2 mesa 19.1.2-1 xf86-video-amdgpu 19.0.1-1 libdrm 2.4.99-1 After upgrading to the linux kernel 5.2 from the Arch Linux repositories, my laptop started to show graphical corruption in Firefox or Konsole. It is mu= ch worse if something is moving on the screen e.g., a video is playing. Someti= mes Firefox is almost unusable as a result. A downgrade to 5.1.16 immediately f= ixes the issues. Somebody mentioned similar corruption for bug 109206: https://bugs.freedesktop.org/show_= bug.cgi?id=3D109206#c57 My kernel command line is: initrd=3D\amd-ucode.img initrd=3D\initramfs-linux.img root=3DPARTUUID=3D34098e4c-f1bf-4a43-a0a8-2ba3ed3c71a6 idle=3Dnomwait psmouse.synaptics_intertouch=3D1 acpi_osi=3DLinux amdgpu.gpu_recovery=3D1 ivrs_ioapic[32]=3D00:14.0 I used to have iommu=3Dpt or iommu=3Doff on the command line to get this la= ptop to boot properly but I have not needed that switch for a while. I might try to reintroduce it with 5.2 just to see what happens. In any case, my setup wor= ked before, so something does not seem right.
Created attachment 144772 [detai=
ls]
Xorg log
Reintroducing iommu=3Dpt does, indeed, seem to fix these graph= ical issues. Why is this flag suddenly required for proper operation again? Is every laptop with an Raven Ridge APU different here or why can the kernel not just figure out how to properly configure the IOMMU so that everything works?
I think that I'm seeing something related with my 2700u Inspir= on 7375. If I have compositing enabled in XFWM4, the system will immediately stop responding after logging in with LightDM. If the window manager compositing= is disabled, I'm able to log in, but then there is graphical corruption. With git bisect I traced the problem back to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?h=3Ddf8368be1382&id=3Ddf8368be1382b442384507a5147c89978cd60702 I can edit the source file, and by only changing the KMS_DRIVER_MINOR definition from 32 to 30, get the system working correctly with 5.2.0.
Same symptoms here after upgrading from Linux 5.1 to 5.2 on De= ll Latitude 5495, Ryzen Pro 2700U. Graphical corruption, and/or the GUI will stop responding. Magic SysRq is needed to reboot the computer. kernel log contains the following bits when this happens: [ 44.921571] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled seq=3D1112, emitted seq=3D1115 [ 44.921574] [drm:amdgpu_job_timedout] *ERROR* Process information: proce= ss X pid 4477 thread X:cs0 pid 4587 [ 44.921575] [drm] GPU recovery disabled.
| What | Removed | Added |
|---|---|---|
| CC | riku@sdf-eu.org |
Another confimation of same issue on HP Envy x360 15-bq181no w= ith Ryzen 5 2500U with Manjaro. Kernel option iommu=3Dpt fixes it, didn't try other workaroun= ds.
(In reply to Brian Schott from comment #3) > I think that I'm seeing something related with m= y 2700u Inspiron 7375. >=20 > If I have compositing enabled in XFWM4, the system will immediately st= op > responding after logging in with LightDM. If the window manager compos= iting > is disabled, I'm able to log in, but then there is graphical corruptio= n. >=20 > With git bisect I traced the problem back to > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?h=3Ddf8368be1382&id=3Ddf8368be1382b442384507a5147c89978cd60702 >=20 > I can edit the source file, and by only changing the KMS_DRIVER_MINOR > definition from 32 to 30, get the system working correctly with 5.2.0.= Your issue in particular is likely unrelated - it's an issue in userspace. The bisected commit is the one that allowed xf86-video-amdgpu to start scan= ning out DCC compressed buffers that mesa produces, with the caveat that mesa ne= eds a hook on present for the re-tile. My guess is that hook isn't running when= you aren't using "compositing". I'm not sure if mesa or xf86-video-amdgpu have options yet to disable DCC or not, but for that particular setup you'd probably want it disabled.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D111244 |
I have the same problem using the Lenovo 530S-14ARR with Ryzen= 5 2500U.=20 The XFCE4 compositing makes the system immediately freeze as soon as I log = in on Manjaro with the 5.2.4-1 kernel. On the 5.3rc2 kernel, I can enable it and it doesn't immediately hang witho= ut recovery. That said, the compositing doesn't work and we have a lot of corruption as soon as anything updates on screen. The "iommu=3Dpt" option didn't do anything for me in regards to r= educing the corruption. I didn't know which logs to include so I didn't. Send reply with the names = and hopefully, approximate path of any logs to include.
| What | Removed | Added |
|---|---|---|
| CC | maraeo@gmail.com, pierre-eric.pelloux-prayer@amd.com |
(In reply to Nicholas Kazlauskas from comment #6) > The bisected commit is the one that allowed xf86= -video-amdgpu to start > scanning out DCC compressed buffers that mesa produces, with the cavea= t that > mesa needs a hook on present for the re-tile. My guess is that hook is= n't > running when you aren't using "compositing". Yeah, could be that radeonsi is missing cases where this hook needs to run = (or DCC needs to be disabled altogether). Pierre or Marek, can you look into this?
(In reply to Brian Schott from comment #3) > I think that I'm seeing something related with m= y 2700u Inspiron 7375. >=20 > If I have compositing enabled in XFWM4, the system will immediately st= op > responding after logging in with LightDM. If the window manager compos= iting > is disabled, I'm able to log in, but then there is graphical corruptio= n. >=20 > With git bisect I traced the problem back to > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?h=3Ddf8368be1382&id=3Ddf8368be1382b442384507a5147c89978cd60702 >=20 > I can edit the source file, and by only changing the KMS_DRIVER_MINOR > definition from 32 to 30, get the system working correctly with 5.2.0.= I couldn't reproduce the problem (Ryzen 7 PRO 2700U laptop). Could you list the version number of the various component involved (kernel, mesa, xf86-video-amdgpu and libdrm) please? Also can you reproduce the problem with another desktop environment?
Just rebuilt mesa, libdrm, and xf86-video-amdgpu from git this= evening. The kernel is the gentoo patched version of 5.2.6. The problem is not limited to XFCE's window manager. This is what it looks like in Dolphin: https://i.imgur.com/b8VLVP6.png=
(In reply to Pierre-Eric Pelloux-Prayer from comment #9) > Could you list the version number of the various= component involved (kernel, > mesa, xf86-video-amdgpu and libdrm) please? kernel 5.2.7 mesa 19.0.8 libdrm 2.4.97 xf86-video-amdgpu 19.0.1 llvm 7.1.0
(In reply to Brian Schott from comment #10) > Just rebuilt mesa, libdrm, and xf86-video-amdgpu= from git this evening. The > kernel is the gentoo patched version of 5.2.6. The problem is not limi= ted to > XFCE's window manager. This is what it looks like in Dolphin: > https://i.imgur.com/b8VLVP= 6.png Does using "AMD_DEBUG=3Dnodcc" Mesa environment variable help? Could you capture an apitrace of the issue in Dolphin so I can reproduce mo= re easily?
(In reply to Pierre-Eric Pelloux-Prayer from comment #12) > Does using "AMD_DEBUG=3Dnodcc" Mesa en= vironment variable help? It does. Exporting that in my ~/.profile makes the desktop usable. > Could you capture an apitrace of the issue in Do= lphin so I can reproduce > more easily? It seems that the Dolphin issue is not related to the desktop graphics corruption. I tested it again using a kernel that had my hack to under-repo= rt the version number and saw the same rendering issues in Dolphin, but that kernel doesn't require the nodcc environment variable.
![https://i.imgur.com/b8VLVP6.png=](3D"https://i.imgur.com/b8VLVP6.png"){kind=link}
Created attachment 145035 [det=
ails]
screenshot
Setting AMD_DEBUG=3D"nodcc" system-wide via /etc/profile will hel=
p against GUI
freeze, but not against graphical corruption (screenshot attached).
It seems that the graphics corruption on my Dell Latitude 5495= with kernel 5.2 is a different issue. Kai-Heng Feng bisected and identified this in the Ubu= ntu Launchpad tracker already. https://bugs.launchpad.net/ubuntu/+source/linu= x/+bug/1837688#yui_3_10_3_1_1565621082983_410
(In reply to Brian Schott from comment #13) > (In reply to Pierre-Eric Pelloux-Prayer from comment #12) > > Does using "AMD_DEBUG=3Dnodcc" Mesa environment variabl= e help? >=20 > It does. Exporting that in my ~/.profile makes the desktop usable. > Let's focus on this issue first. Can you paste the output of: "AMD_DEBUG=3Dinfo glxgears" please? And would you be able to test other versions of Mesa to see if your issue c= ould be bisected (if it happens to be a Mesa problem)?
| What | Removed | Added |
|---|---|---|
| CC | briancschott@gmail.com |