| Summary: | Radeon 7870 XT Stalling Between Ring 0 and Ring 3 | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Ben <benli1392> |
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | XOrg git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 118951 [details]
x.org log from tumbleweed's kernel
Created attachment 118952 [details]
dmesg.log from upstream's version of the kernel
Created attachment 118953 [details]
x.org.log from upstream's version of the kernel
Which version of mesa and libdrm do you have? Does it work with Option "DRI" "3" in xorg.conf? libdrm version is currently 2.4.65 and Mesa version is currently 11. I just updated my Tumbleweed install and am now using kernel version 4.2.3. Created attachment 118965 [details]
dmesg with kernel 4.2.3
Created attachment 118966 [details]
x.org log with kernel 4.2.3
The new logs are created with option "dri" "3" added to 50-device.conf I just checked the logs again and I found out that I did not enable DRI3 correctly.
I updated my openSUSE Tumbleweed system to kernel 4.3 and tried to enable DRI3 by creating a 20-radeon.conf file at /etc/X11/xorg.conf.d/ with the contents:
Section "Device"
Identifier "Radeon 7870 XT"
Option "DRI3" "on"
EndSection
I restarted and checked the Xorg.0.log and it seems that DRI3 is not used even when specified to. I am attaching the newest dmesg and xorg logs.
Created attachment 119389 [details]
dmesg log with kernel 4.3
Created attachment 119390 [details]
xorg log with kernel 4.3
(In reply to benli1392 from comment #9) > I updated my openSUSE Tumbleweed system to kernel 4.3 and tried to enable > DRI3 by creating a 20-radeon.conf file at /etc/X11/xorg.conf.d/ with the > contents: > > Section "Device" > Identifier "Radeon 7870 XT" > Option "DRI3" "on" > EndSection Please just put this in /etc/X11/xorg.conf. The xorg.conf.d mechanism is for shipping configuration snippets in packages. > I restarted and checked the Xorg.0.log and it seems that DRI3 is not used > even when specified to. I am attaching the newest dmesg and xorg logs. Your Xorg radeon driver is too old, DRI3 is only supported by recent xf86-video-ati Git. I followed your recommendations and created a xorg.conf in /etc/X11/ and removed 20-radeon.conf from /etc/X11/xorg.conf.d/. DRI3 is also enabled when I added a repo with xf86-video-ati that is much more up to date: http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_Tumbleweed/ It has gotten better, but it still does not work with a newer version of the driver. dmesg seems to have dumped a lot of information on the radeon driver. I am attaching an updated dmesg and xorg log. Created attachment 119474 [details]
dmesg log with newer version of xf86-video-ati.
Created attachment 119475 [details]
xorg log with newer version of xf86-video-ati.
*** This bug has been marked as a duplicate of bug 60879 *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 118950 [details] dmesg.log from Tumbleweed's kernel System: Opensuse Tumbleweed, but same problem exist on different distributions. Reproducible: Always Steps to Reproduce: 1. Boot up system 2. Opensuse boots up with plymouth without much issue. 3. X tries to start, but crashes 4. Opensuse goes to the terminal login 5. The stall messages continue non-stop. Sample of stall messages: [ 68.950045] radeon 0000:01:00.0: ring 0 stalled for more than 14020msec [ 68.970866] radeon 0000:01:00.0: ring 3 stalled for more than 10479msec Hardware information: CPU: AMD FX-8320 Motherboard: Gigabyte GA-970A-D3P Graphics card: Powercolor 7870 XT Myst Edition (Latest firmware .32 w/ UEFI support) Tested on different kernel versions from 42.1 branch, Tumbleweed, and stable (upstream). Brand of 7870 XT card does not seem to matter. Another user online had a Sapphire brand card and the user had the exact same problems.