[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

GitLab Migration User  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEEDINFO|RESOLVED

--- Comment #212 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1222.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #210 from emilio.more...@gmail.com ---
(In reply to Sandeep from comment #209)
> Created attachment 141193 [details]
> attachment-13440-0.html
> 
> Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
> If not, then it's a bug in the driver.

THANK YOU

Now it works. Looks like the DC code was causing troubles.

This is my current configuration for grub
GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=0 amdgpu.cik_support=1
amdgpu.modeset=1 amdgpu.dc=0 amdgpu.dpm=1"
I'm on kernel 4.18.3.

I left the PC running for hours and it didn't freeze. This was simply
impossible before the new changes.

I also tried reducing the monitor shutdown to 1 minute, and it worked every
single time I left it idle.

I think that I can finally confirm I'm no longer able to reproduce this bug,
after 2 and a half years of using this card, and trying new kernels once a
month.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #211 from Filip Brygidyn  ---
Thank you for fixing this, I wanted to report that in my case enabling DC does
not seem to cause any issues.
I am running amdgpu (no 'amdgpu pro' drivers on top) with following params:
"amdgpu.cik_support=1 amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1"

Kernel version: 4.17.14 (arch)
GPU: MSI R9 390 Gaming 8G

Anyone knows which patches fixed this?
Link to a mailing list patch-set or a git hash on the mainline branch would be
much appreciated.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #209 from Sandeep  ---
Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
If not, then it's a bug in the driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #208 from emilio.more...@gmail.com ---
(In reply to emilio.moretti from comment #207)
> (In reply to Sandeep from comment #206)
> > You've got to make sure that radeon and amdgpu drivers don't clash.
> > 
> > Try the following kernel parameters: radeon.si_support=0
> > radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dpm=1
> > 
> > That's what I use and it works fine for me.
> 
> Thanks, but I did that. Here is my process:
> 
> Stable system configuration (power management doesn't crash):
> 1) Make sure amdgpu is blacklisted:
> # vim /etc/modprobe.d/blacklist.conf
> -> add "blacklist amdgpu" at the bottom
> # update-initramfs -u -k all
> 
> 2) Update grub parameters:
> # vim /etc/default/grub
> -> Set the correct defaults:
> GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=1 amdgpu.cik_support=0"
> # update-grub
> 
> 3) reboot the system
> 
> 
> Unstable system configuration (power management crashes the entire system
> when it tries to power off the monitors):
> 1) Make sure amdgpu can be loaded:
> # vim /etc/modprobe.d/blacklist.conf
> -> add "blacklist amdgpu" at the bottom
> # update-initramfs -u -k all
> 
> 2) Update grub parameters:
> # vim /etc/default/grub
> -> Set the correct defaults:
> GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=0 amdgpu.cik_support=1
> amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1"
> # update-grub
> 
> 3) reboot the system
> 
> 
> It's a fairly easy way to test it as is freezes every time you leave the PC
> idle. I haven't seen it crash during my daily usage, but it does crash when
> the power management kicks in.

oh, sorry. There is a "typo" in my previous answer. For the unstable system you
need to remove amdgpu from the blacklisted modules. Let me "correct" the
unstable system configuration:

1) Make sure amdgpu can be loaded:
# vim /etc/modprobe.d/blacklist.conf
-> REMOVE "blacklist amdgpu" at the bottom
# update-initramfs -u -k all

2) Update grub parameters:
# vim /etc/default/grub
-> Set the correct defaults: GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=0
amdgpu.cik_support=1 amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1"
# update-grub

3) reboot the system

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #207 from emilio.more...@gmail.com ---
(In reply to Sandeep from comment #206)
> You've got to make sure that radeon and amdgpu drivers don't clash.
> 
> Try the following kernel parameters: radeon.si_support=0
> radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dpm=1
> 
> That's what I use and it works fine for me.

Thanks, but I did that. Here is my process:

Stable system configuration (power management doesn't crash):
1) Make sure amdgpu is blacklisted:
# vim /etc/modprobe.d/blacklist.conf
-> add "blacklist amdgpu" at the bottom
# update-initramfs -u -k all

2) Update grub parameters:
# vim /etc/default/grub
-> Set the correct defaults: GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=1
amdgpu.cik_support=0"
# update-grub

3) reboot the system


Unstable system configuration (power management crashes the entire system when
it tries to power off the monitors):
1) Make sure amdgpu can be loaded:
# vim /etc/modprobe.d/blacklist.conf
-> add "blacklist amdgpu" at the bottom
# update-initramfs -u -k all

2) Update grub parameters:
# vim /etc/default/grub
-> Set the correct defaults: GRUB_CMDLINE_LINUX_DEFAULT="radeon.cik_support=0
amdgpu.cik_support=1 amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1"
# update-grub

3) reboot the system


It's a fairly easy way to test it as is freezes every time you leave the PC
idle. I haven't seen it crash during my daily usage, but it does crash when the
power management kicks in.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #206 from Sandeep  ---
You've got to make sure that radeon and amdgpu drivers don't clash.

Try the following kernel parameters: radeon.si_support=0 radeon.cik_support=0
amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dpm=1

That's what I use and it works fine for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #205 from emilio.more...@gmail.com ---
kernel >4.17 did NOT work.

It didn't hang while using the PC, but it did freeze when the power management
tried to power off my both monitors. One of them was successfully powered off,
while the other showed the mouse cursor in the screen. 

There are no system logs, as it froze so hard that not even "REISUB" worked.

Again, this works OK using Radeon.


Details:
kernel 4.18.1
Ubuntu 18.04.1 + stock Mesa (no upgrades here)
Sapphire AMD GPU 390x 8GB
DVI + Display port connected. The display port actually has an adapter to get
VGA, and the DVI goes straight to the 1080p dell monitor.
The monitor that worked OK when turned off was connected to the VGA adapter in
the display port. The DVI port was the one that showed the mouse cursor.

Running on a Ryzen 1800X. The processor had his own stability problems a few
months ago, but a BIOS update fixed that.

The only way to get the PC to a stable state with the amd 390x is to blacklist
amdgpu, so the power management doesn't freeze the system when I leave it alone
for a couple of minutes.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #204 from tkdestroyer2+bugs-freedesk...@gmail.com ---
(In reply to iburnth3playb00k from comment #203)
> (In reply to chris from comment #188)
> > I suffered pretty much all of the issue listed in this thread for many weeks
> > since upgrading to 3 1440p monitors.
> > 
> > I have an Club 3D R9 390 Royal Queen.
> > 
> > Comment #182 best describes the problem I faced and what I had to do to work
> > around it.
> > 
> > I am happy to announce that kernel 4.16.7 has solved this issue for me.
> > 
> > My system has no more issues booting. KDE is stable. No flickering at all.
> > Even when forcing power_dpm_force_performance_level to 'low'.
> > 
> > I'm running Gentoo with:
> > mesa-18.1.0
> > libdrm-2.4.91
> > xf86-video-amdgpu-18.0.1
> > xorg-drivers-1.19
> > 
> > kernel params include: radeon.cik_support=0 amdgpu.cik_support=1
> > amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1
> > 
> > If anyone needs more info please ask.
> 
> Im kinda new to linux and i have this problem.
> Can you create a step by step guide to help me fix the problem?

You need to:

a) Upgrade the kernel to a newer version.

b) Add boot parameters

There are guides online for these. Search for one in your distribution (e.g.
Gentoo, Arch, Ubuntu).


I myself still get kernel panics on latest (4.17.12) and freezes and whatnot.
Older versions with dpm=0 are my only success.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #203 from iburnth3playb00k  ---
(In reply to chris from comment #188)
> I suffered pretty much all of the issue listed in this thread for many weeks
> since upgrading to 3 1440p monitors.
> 
> I have an Club 3D R9 390 Royal Queen.
> 
> Comment #182 best describes the problem I faced and what I had to do to work
> around it.
> 
> I am happy to announce that kernel 4.16.7 has solved this issue for me.
> 
> My system has no more issues booting. KDE is stable. No flickering at all.
> Even when forcing power_dpm_force_performance_level to 'low'.
> 
> I'm running Gentoo with:
> mesa-18.1.0
> libdrm-2.4.91
> xf86-video-amdgpu-18.0.1
> xorg-drivers-1.19
> 
> kernel params include: radeon.cik_support=0 amdgpu.cik_support=1
> amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1
> 
> If anyone needs more info please ask.

Im kinda new to linux and i have this problem.
Can you create a step by step guide to help me fix the problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #202 from Ioannis Panagiotopoulos  ---
Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland
and the right boot arguments. However this worked when I had the R9 390
installed alone. When I used both the R9 390 and Rx 550 on the same system, the
display plugged on the R9 390 did not work correctly and produced broken UI
elements from time to time. Furthermore UI was very slow on response.
When tried Fedora 28 KDE, SDDM was constantly crashing when it tried to start
and stuck on a loop try-to-start->crash->try-to-start.
Kubuntu 18.04 KDE worked, but had the same issues as Fedora 28 Gnome.
So it seems the dpm bug is at last solved despite the other problems that might
be unrelated to dpm.

(In reply to heavyjoe from comment #201)
> (In reply to Sandeep from comment #200)
> > You can probably ignore the warnings, I get them too and nothing bad has
> > happened so far. As long as GPU hang doesn't occur, it's all good.
> 
> Thanks for the reply.
> In the problem reporting app it is written as
> "Unexpeted System Error" The system has encountered a problem and recovered.
> 
> The reason is as i wrote:
> WARNING: CPU: 1 PID: 369 at
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
> generic_reg_update_ex+0x12c/0x160 [amdgpu]
> 
> so the system errors can occur as warnings? then i can live with it but i
> wasn't sure because it was labeled as system error...
> 
> thanks again. i will go on with that and hope no freezes appear.

if you installed the kernel manually, then try to install the
kernel-modules-extra package of this kernel version as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #201 from heavy...@web.de ---
(In reply to Sandeep from comment #200)
> You can probably ignore the warnings, I get them too and nothing bad has
> happened so far. As long as GPU hang doesn't occur, it's all good.

Thanks for the reply.
In the problem reporting app it is written as
"Unexpeted System Error" The system has encountered a problem and recovered.

The reason is as i wrote:
WARNING: CPU: 1 PID: 369 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x12c/0x160 [amdgpu]

so the system errors can occur as warnings? then i can live with it but i
wasn't sure because it was labeled as system error...

thanks again. i will go on with that and hope no freezes appear.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #200 from Sandeep  ---
You can probably ignore the warnings, I get them too and nothing bad has
happened so far. As long as GPU hang doesn't occur, it's all good.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

heavy...@web.de changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO

--- Comment #199 from heavy...@web.de ---
Can someone please help the linux noob?

I am on fedora 28. my "GRUB_CMDLINE_LINUX=" looks like this:

BOOT_IMAGE=/boot/vmlinuz-4.16.7-300.fc28.x86_64 root=/dev/mapper/fedora-root ro
rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet radeon.si_support=0
radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dc=1
amdgpu.dpm=1

i added the "amdgpu.dc=1 amdgpu.dpm=1"
when i start gnome there are 3 errors like this:

WARNING: CPU: 2 PID: 369 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x12c/0x160 [amdgpu]

what parts of the grub-line do i need to add or delete to get things working,
fixed as suggested in this thread? do i still have the wrong kernel?

Thanks very much!!! I really try to make the switch to linux but the problems
with my ASUS R9 390 DirectCU III OC (and the bad performance) are a bit
annoying.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #198 from Jon Doane  ---
I would like to add that the problem appears to be resolved on my installation
of Ubuntu 18.04 with the MSI R9 390 8GB GAMING GPU using the current mainline
kernel (4.17-rc4,) with the kernel flags of "amdgpu.dc=1" and "amdgpu.dpm=1".
Clock scaling appears to be working as expected and I haven't had any visual
artifacts or crashes to speak of yet. Using "amdgpu.dc=1" alone didn't make a
difference but, "amdgpu.dpm=1" made all the difference.

Good work to everyone involved!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #197 from Sandeep  ---
Anyway, thanks for fixing the bug, AMD devs! (or whoever else did it).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #196 from Sandeep  ---
Ah, I didn't know that. I thought it just disabled/enabled dpm...well,
it works so that's good.

It would be great if it worked out of the box though, without having to add
kernel parameters.

On Fri, May 11, 2018, 14:39  wrote:

> *Comment # 195 
> on bug 91880  from Alex
> Deucher  *
>
> (In reply to Sandeep from comment #194 
> )> So, I had never 
> used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> > testing earlier.
> >
> > I tried using them now, with the 4.16.7 kernel, and replayed the APItrace
> > file. No crashes! Finally.
> >
> > Well, this is still a workaround, but atleast it works. I doubt it has
> > anything to do with DC, although it's possible..
>
> setting dpm=1 uses the new powerplay code rather than the old dpm code for
> power management on CI parts.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #195 from Alex Deucher  ---
(In reply to Sandeep from comment #194)
> So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> testing earlier.
> 
> I tried using them now, with the 4.16.7 kernel, and replayed the APItrace
> file. No crashes! Finally.
> 
> Well, this is still a workaround, but atleast it works. I doubt it has
> anything to do with DC, although it's possible..

setting dpm=1 uses the new powerplay code rather than the old dpm code for
power management on CI parts.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #194 from Sandeep  ---
So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
testing earlier.

I tried using them now, with the 4.16.7 kernel, and replayed the APItrace file.
No crashes! Finally.

Well, this is still a workaround, but atleast it works. I doubt it has anything
to do with DC, although it's possible..

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

no...@amail.club changed:

   What|Removed |Added

 Resolution|WORKSFORME  |---
 Status|RESOLVED|REOPENED

--- Comment #193 from no...@amail.club ---
(In reply to Sandeep from comment #192)
> I tested with the APItrace file that I uploaded, still broken on 4.16.7 .

I updated to 4.16.7 and replayed the APItrace file uploaded in comment #181
I also tried setting the env variable vblank_mode=0, so there was no vsync/fps
cap.
I then tried suspending and resuming, and rerunning the APItrace, and it was
fine.
I did not experience any artifacting or corruptions in either test.

So there are still issues with the XFX branded R9 390. :(

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #192 from Sandeep  ---
I tested with the APItrace file that I uploaded, still broken on 4.16.7 .

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #191 from no...@amail.club ---
I did some more testing this time with Arch Linux, I started with kernel
4.16.6-1, and went back two months, one month at a time using the Arch Linux
Archive. I never ran into an issue.
It would seem that this issue might have been fixed a few months ago.

The solution is to switch from Radeon, to AMDGPU. It seems that AMDGPU DPM is
needed to fix the issue entirely, at least in my case.

device: MSI R9 390 Gaming 8G
distro: Arch Linux
kernel: 4.16.6-1, 4.15.13-1 and 4.15.5-1
mesa: 18.0.2-1, 17.3.7-1 and 17.3.5-1
xorg-server: 1.19.6+13+gd0d1a694f-1
xf86-video-amdgpu: 18.0.1-1 and 1.4.0-1

In all cases I appended the following kernel arguments: radeon.cik_support=0
amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1

radeon.cik_support=0 Disables Radeon CIK(Sea Island) Support
amdgpu.cik_support=1 Enables AMDGPU CIK(Sea Island) Support
amdgpu.dpm=1 Enables DPM support
amdgpu.dc=1 Enables Display Core driver

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #190 from no...@amail.club ---
With 4.16.6, it seems to be fixed!
With a fresh installation of Antergos 18.4, tested with different kernel
arguments, `radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1` is all
that's needed to work fine.
amdgpu.modeset=1 does not actually do anything according to logs.
I ran different tests from glxgears to unigine valley and heaven, they seemed
to work fine without any issues.

hardware: MSI R9 390 Gaming 8G
kernel: 4.16.6
mesa: 18.0.2
xorg-server: 1.19.6
xf86-video-amdgpu: 18.0.1
kernel arguments: radeon.cik_support=0 amdgpu.cik_support=1 amdgu.dpm=1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #189 from tkdestroyer2+bugs-freedesk...@gmail.com ---
I tried what chris suggested, and it worked up until the point at which some X
session closes (right after login or after exiting basic xterm test session),
where the system locks up. They seem to have patched 4.16.*, which was totally
broken before for me on 4.16.2. I guess I'll keep doing my dpm=0 thing for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

chrisg_...@hotmail.com changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|REOPENED|RESOLVED

--- Comment #188 from chrisg_...@hotmail.com ---
I suffered pretty much all of the issue listed in this thread for many weeks
since upgrading to 3 1440p monitors.

I have an Club 3D R9 390 Royal Queen.

Comment #182 best describes the problem I faced and what I had to do to work
around it.

I am happy to announce that kernel 4.16.7 has solved this issue for me.

My system has no more issues booting. KDE is stable. No flickering at all. Even
when forcing power_dpm_force_performance_level to 'low'.

I'm running Gentoo with:
mesa-18.1.0
libdrm-2.4.91
xf86-video-amdgpu-18.0.1
xorg-drivers-1.19

kernel params include: radeon.cik_support=0 amdgpu.cik_support=1
amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1

If anyone needs more info please ask.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #187 from Lauri Gustafsson  ---
About "I can force a system hard-lock by doing anything which disables a
monitor", on my system it used to crash more frequently the less desktop area I
had. Small resolution monitor crashes often, multi monitor setup less often.
But I don't have the hardware any more so I can't test if it still works that
way.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #186 from Chris Heald  ---
I've been doing a lot of experimentation, and I've found a few more things that
I feel are probably related:

* I can force a system hard-lock by doing anything which disables a monitor.
Notably, going full-screen under KDE/Xorg does this, but I can trigger it just
as easily by disabling a monitor with xrandr. Fullscreen under gnome doesn't
seem to trigger the issue, which I suspect is due to gnome's using mutter for
screen management.

* Occassioanlly, the system boots up and gets stuck with a 150MHz memory clock,
rather than clocking up to the 1500MHz state. This causes the display
corruption even if the sclk is set to 500MHz+. Setting the mclk mask manually
fixes display corruption.

* I've been experimenting with different kernels ranging from 4.4 to 4.16rc5.
Earlier kernels feel more susceptible to hard-locking, though the later kernels
aren't immune to it.

* I tried a fresh Ubuntu 16.04 LTS install, and while it did NOT exhibit the
artifacting behavior, the system hard-locked within a few minutes of light
desktop usage.

I've had a few classes of exceptions show up in kern.log:

On 4.4, my kde/wayland session hard-froze when moving a window, and produced a
log like this:

kernel: [  116.904013] radeon :06:00.0: GPU fault detected: 146 0x0d8e040c
kernel: [  116.904017] radeon :06:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR
  0x0001776C
kernel: [  116.904019] radeon :06:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E10400C
kernel: [  116.904021] VM fault (0x0c, vmid 7) at page 96108, read from 'TC3'
(0x54433300) (260)
kernel: [  127.306156] radeon :06:00.0: ring 0 stalled for more than
10404msec
kernel: [  127.306164] radeon :06:00.0: GPU lockup (current fence id
0x2419 last fence id 0x2431 on ring 0)
kernel: [  127.357942] radeon :06:00.0: Saved 2200 dwords of commands on
ring 0.
kernel: [  127.357961] radeon :06:00.0: GPU softreset: 0x0009
kernel: [  127.357963] radeon :06:00.0:   GRBM_STATUS=0xF5D01028
kernel: [  127.357965] radeon :06:00.0:   GRBM_STATUS2=0x5008
kernel: [  127.357968] radeon :06:00.0:   GRBM_STATUS_SE0=0xEC42
kernel: [  127.357970] radeon :06:00.0:   GRBM_STATUS_SE1=0xEC42
kernel: [  127.357972] radeon :06:00.0:   GRBM_STATUS_SE2=0x0802
kernel: [  127.357974] radeon :06:00.0:   GRBM_STATUS_SE3=0xEC02
kernel: [  127.357976] radeon :06:00.0:   SRBM_STATUS=0x2040
kernel: [  127.357978] radeon :06:00.0:   SRBM_STATUS2=0x
kernel: [  127.357980] radeon :06:00.0:   SDMA0_STATUS_REG   = 0x46CEE557
kernel: [  127.357982] radeon :06:00.0:   SDMA1_STATUS_REG   = 0x46CEE557
kernel: [  127.357984] radeon :06:00.0:   CP_STAT = 0x84228600
kernel: [  127.357986] radeon :06:00.0:   CP_STALLED_STAT1 = 0x0c00
kernel: [  127.357988] radeon :06:00.0:   CP_STALLED_STAT2 = 0x4000
kernel: [  127.357991] radeon :06:00.0:   CP_STALLED_STAT3 = 0x0400
kernel: [  127.357993] radeon :06:00.0:   CP_CPF_BUSY_STAT = 0x0006
kernel: [  127.357995] radeon :06:00.0:   CP_CPF_STALLED_STAT1 = 0x0003
kernel: [  127.357997] radeon :06:00.0:   CP_CPF_STATUS = 0x8063
kernel: [  127.357999] radeon :06:00.0:   CP_CPC_BUSY_STAT = 0x
kernel: [  127.358001] radeon :06:00.0:   CP_CPC_STALLED_STAT1 = 0x
kernel: [  127.358003] radeon :06:00.0:   CP_CPC_STATUS = 0x
kernel: [  127.358005] radeon :06:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR
  0x
kernel: [  127.358007] radeon :06:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x
kernel: [  127.404670] radeon :06:00.0: GRBM_SOFT_RESET=0x00010001
kernel: [  127.404725] radeon :06:00.0: SRBM_SOFT_RESET=0x0100
kernel: [  127.405874] radeon :06:00.0:   GRBM_STATUS=0x3028
kernel: [  127.405876] radeon :06:00.0:   GRBM_STATUS2=0x0008
kernel: [  127.405878] radeon :06:00.0:   GRBM_STATUS_SE0=0x0006
kernel: [  127.405880] radeon :06:00.0:   GRBM_STATUS_SE1=0x0006
kernel: [  127.405882] radeon :06:00.0:   GRBM_STATUS_SE2=0x0006
kernel: [  127.405884] radeon :06:00.0:   GRBM_STATUS_SE3=0x0006
kernel: [  127.405885] radeon :06:00.0:   SRBM_STATUS=0x2A40
kernel: [  127.405887] radeon :06:00.0:   SRBM_STATUS2=0x
kernel: [  127.405889] radeon :06:00.0:   SDMA0_STATUS_REG   = 0x46CEE557
kernel: [  127.405891] radeon :06:00.0:   SDMA1_STATUS_REG   = 0x46CEE557
kernel: [  127.405893] radeon :06:00.0:   CP_STAT = 0x
kernel: [  127.405893] radeon :06:00.0:   CP_STAT = 0x
kernel: [  127.405895] radeon :06:00.0:   CP_STALLED_STAT1 = 0x
kernel: [  127.405896] radeon :06:00.0:   CP_STALLED_STAT2 = 0x
kernel: [  127.405898] radeon :06:00.0:   CP_STALLED_STAT3 = 0x
kernel: [  127.405900] radeon :06:00.0:   

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #185 from Sandeep  ---
I have that display/corruption issue too, on the XFX R9 390.

Usually happens after suspend/resume. Will test if it gets fixed with above
steps.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #184 from Chris Heald  ---
Created attachment 138059
  --> https://bugs.freedesktop.org/attachment.cgi?id=138059=edit
dmesg output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Chris Heald  changed:

   What|Removed |Added

 CC||che...@gmail.com

--- Comment #183 from Chris Heald  ---
Created attachment 138058
  --> https://bugs.freedesktop.org/attachment.cgi?id=138058=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #182 from Chris Heald  ---
Just adding a data point here, I've got an MSI R9 390 running on Ubuntu 18.04
on 4.15.0-10-generic - I haven't had any stability issues, but I have had
maddening screen flickering/corruption.

I'm running dual 2560x1440 monitors off the card, which forces the memory clock
to 1500MHz. However, when the GPU clock is at the 300MHz level, I get
horrendous artifacting any time an accelerated portion of the screen is drawn.
I can easily reproduce the issue by mousing over certain KDE widgets which are
acclerated. Interestingly, running glxgears doesn't cause the issue.

* Setting power_dpm_force_performance_level -> high fixes it (but runs the
clock up to its max, obviously)
* Setting power_dpm_force_performance_level -> manual and then `echo 1234567 >
pp_dpm_sclk` fixes it, with the GPU clock fixed to 500MHz.

I've been up and down this issue with both radeon and amdgpu drivers; neither
seems to make a difference.

# lspci -nnk | grep -iA2 vga
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Hawaii PRO [Radeon R9 290/390] [1002:67b1] (rev 80)
Subsystem: Micro-Star International Co., Ltd. [MSI] Hawaii PRO [Radeon
R9 290/390] [1462:2015]
Kernel driver in use: amdgpu

# cat vbios_version
MS-V30823-F6

(Interestingly, this BIOS is newer than anything on techpowerup. I was hoping a
BIOS flash would fix it, but I can't find anything newer)

I'll attach dmesg and Xorg logs as well. If I can provide extra data points,
I'd like to help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #181 from Sandeep  ---
I was able to reliably reproduce the bug with openarena on my XFX R9 390 -
here's a link to a trace file (1.8 GB) -
https://drive.google.com/file/d/1YbOtWheR9RJdqnwya1rMNw1NphVptAUX/view?usp=sharing

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #180 from x...@amail.club ---
>From watching this bug progress over the last two years and not really
improving, I guess this problem is never going to get fixed, at least not too
soon.

>From my testing last year, it would seem that the majority who have this
problem own the MSI brand one, both 390 an 390x have the problem, and there
isn't a proper workaround for it besides forcing the memory(maybe core) clock
high, so it would seem that the clock is not being set correctly, or the
"sensor" isn't realizing that clock should be increased.

I have tried every kernel from the past year in hopes that this problem would
be solved, with no successful test, I have tried using both AMDGPU and radeon
modules, while blacklisting the other to make sure that there was not a problem
with one, and still no success.

On Windows 10, there is never an issue with artifacts, or crashes.

If there is anyway to get this on a fast track to being fixed, please let
everyone know, so that we can help, that is what community is for...I think.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #179 from Thomas DEBESSE  ---
Andrea Zanoni, can you print the output of this command?

lspci -nn | grep VGA

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #178 from Andrea Zanoni  ---
I have the same issues with an MSI R9 390 running on a MSI Z170A GAMING M5
motherboard.

The only way I can even use the card, avoiding constant black screens and os
lockup, is to use the DPM Query service
(https://github.com/illwieckz/dpm-query/) and force the dpm level on "high" and
the state profile on "performance". 

If I try to revert to the "low" level, I get this: 

ERROR: card0/power_dpm_force_performance_level does not accept "low"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #177 from garththei...@hotmail.com ---
Created attachment 134324
  --> https://bugs.freedesktop.org/attachment.cgi?id=134324=edit
dmesg capture

Logged this problem against 4.13.2. Started up an accelerated program (game)
and with in seconds the screen went black.

In the attached dmesg output the amdgpu emits a timeout *ERROR*, but I was
unable to recover the session/switch DPM parameters to force recovery.

>[   85.983053] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, 
>last signaled seq=2103, last emitted seq=2105
>[   85.983125] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
>last signaled seq=7839, last emitted seq=7841
>[   85.983129] [drm] No hardware hang detected. Did some blocks stall?
>[   85.983130] [drm] No hardware hang detected. Did some blocks stall?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #176 from Jon Doane  ---
(In reply to Thomas DEBESSE from comment #175)
> (In reply to Alex Deucher from comment #174)
> > (In reply to Thomas DEBESSE from comment #173)
> > > 
> > > Their AMDGPU-PRO driver looks to not be affected by the bug, so they have 
> > > a
> > > fix somewhere. Why this fix can't make it's way to the open driver?
> > 
> > The pro stack and the open stack share the same amdgpu kernel driver.
> 
> Yes I know, so what?
> 
> Is this a packaging issue like the firmware delivered not being the good one
> or things like that?

I've experienced this issue with both AMDGPU-Pro and AMDGPU with the same
visual artifacts out of the box. The radeon driver seems to not have the same
kind of visual artifacts that AMDGPU(-Pro) has but, it's just as unstable
without intervention, at least for me. Changing the firmware didn't make enough
of an impact to make my machine even close to stable by itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #175 from Thomas DEBESSE  ---
(In reply to Alex Deucher from comment #174)
> (In reply to Thomas DEBESSE from comment #173)
> > 
> > Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> > fix somewhere. Why this fix can't make it's way to the open driver?
> 
> The pro stack and the open stack share the same amdgpu kernel driver.

Yes I know, so what?

Is this a packaging issue like the firmware delivered not being the good one or
things like that?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #174 from Alex Deucher  ---
(In reply to Thomas DEBESSE from comment #173)
> 
> Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> fix somewhere. Why this fix can't make it's way to the open driver?

The pro stack and the open stack share the same amdgpu kernel driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #173 from Thomas DEBESSE  ---
(In reply to Jon Doane from comment #172)
> Unless something has changed with how the dpm state is handled, I don't
> expect that to make the system completely stable. They're more stable than
> balanced but, it's not stable enough to prevent a crash.

Hmm, until now the discussion only talked about level (low, auto, high) and not
state (battery, balanced, performance), it was suspected "auto" level being
faulty, but no one yet suspected "balanced" state being faulty. It's currently
assumed any state is working but one level is not (auto). Perhaps that's a
wrong assumption by the way. Have you specifically experienced an issue due to
the "balanced" state and not due to the "auto" level that is commonly used with
it?

> The only method that I've had luck with while retaining clock scaling is
> this:
> echo 234567 > /sys/class/drm/card0/device/pp_dpm_sclk
> 
> This disables the 300Mhz clock step which seems to work however

Oh yes I forgot this trick because on my end using "low" or "high" level is
enough so I never had to mess with that. By the way when I'm on "low" level I'm
running at 300MHz and it runs nicely for weeks (i.e. until I reboot for
something unrelated like a kernel upgrade).

> One way or another, I have ways around the problem but, these are hacks that
> would be considered intolerable solutions by a regular user.

Sure, but if no one is going to fix that, it would be better to have these
hacks applied by default and not expecting the user to do them by hand. Since
more than two years now, running a LiveCD to install Linux on a system having
an R9 390X leads to a crash while installing… A by-default hack would be better
than nothing if no one is going to fix it.

I still don't understand why it's so hard for AMD employees to get their hand
on AMD hardware to work on a fix, and we know the faulty models (0x67B0,
0x67B1) and many commercial names were listed.

Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a fix
somewhere. Why this fix can't make it's way to the open driver?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #172 from Jon Doane  ---
(In reply to Thomas DEBESSE from comment #171)
> > This sounds a lot like what I've been doing manually which sounds nice.
> > Thanks for the input. I honestly would like a solution that doesn't cause my
> > machine to draw an additional 90 watts at idle though.
> 
> Unlike the kernel patch above, that systemd service is setting the GPU to
> "low battery" by default, which is the most energy saving profile. The
> provided `dpm query` tool allows you to change that at any time. That's what
> I'm doing: at init, my GPU is set to "low battery" profile, and when I need
> to do some heavy time, I do that:
> 
> dpm-query set all high performance
> 
> And then once the heavy task is done, I do that to save energy again:
> 
> dpm-query set all low battery
> 
> With the default config for the service, you just have to add your own user
> to the "video" group to have the right to change the profile as user.
> 
> So, even if the patch above get merged one day, this service and tool is
> still useful, it's an easy way to change the default profile, whatever the
> default is.
> 
> Notice that the kernel patch above only set the level to "high", but keep
> the state to "balanced", so it's still adaptative. What "high balanced" does
> is setting the shader and memory frequencies to the max, which is drawing
> more power than default, but you will notice the fan are still idling and
> stopped if you do nothing because it's still saving a lot of energy. If you
> set "high performance" the fan will almost instantaneously start because
> there is no saving anymore. So "high balanced" is less energy saving that
> "auto balanced", but is still saving a lot of energy because it does not
> have to cold the chip while doing nothing (meaning the chip does nothing
> strong enough to get hot).

Unless something has changed with how the dpm state is handled, I don't expect
that to make the system completely stable. They're more stable than balanced
but, it's not stable enough to prevent a crash. I tried by starting off with:
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level

The only method that I've had luck with while retaining clock scaling is this:
echo 234567 > /sys/class/drm/card0/device/pp_dpm_sclk

This disables the 300Mhz clock step which seems to work however, I've observed
that doing this also forced memory clocks to full tilt instead of idle so, I'm
uncertain if the memory clock or core clock is responsible.

Something I've observed is that if my machine crashes and I use the reset
button to restart it, that when X loads and if I don't force clocks up, it
always crashes and that part of the old image that was on the screen when it
initially crashed gets displayed, albeit rather garbled but, enough to identify
it which makes me think that it's related to the memory clock or how GPU memory
is managed.

One way or another, I have ways around the problem but, these are hacks that
would be considered intolerable solutions by a regular user.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #171 from Thomas DEBESSE  ---
> This sounds a lot like what I've been doing manually which sounds nice.
> Thanks for the input. I honestly would like a solution that doesn't cause my
> machine to draw an additional 90 watts at idle though.

Unlike the kernel patch above, that systemd service is setting the GPU to "low
battery" by default, which is the most energy saving profile. The provided `dpm
query` tool allows you to change that at any time. That's what I'm doing: at
init, my GPU is set to "low battery" profile, and when I need to do some heavy
time, I do that:

dpm-query set all high performance

And then once the heavy task is done, I do that to save energy again:

dpm-query set all low battery

With the default config for the service, you just have to add your own user to
the "video" group to have the right to change the profile as user.

So, even if the patch above get merged one day, this service and tool is still
useful, it's an easy way to change the default profile, whatever the default
is.

Notice that the kernel patch above only set the level to "high", but keep the
state to "balanced", so it's still adaptative. What "high balanced" does is
setting the shader and memory frequencies to the max, which is drawing more
power than default, but you will notice the fan are still idling and stopped if
you do nothing because it's still saving a lot of energy. If you set "high
performance" the fan will almost instantaneously start because there is no
saving anymore. So "high balanced" is less energy saving that "auto balanced",
but is still saving a lot of energy because it does not have to cold the chip
while doing nothing (meaning the chip does nothing strong enough to get hot).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #170 from Jon Doane  ---
(In reply to Stefan from comment #160)
> Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option.

Crippling GPU performance is not a solution and doesn't alleviate pains because
it basically forces me to not do anything 3d-related. I would rather boot with
X disabled so I can force the perf level to high. This is what I used to do and
it's not an acceptable solution.

(In reply to Thomas DEBESSE from comment #164)
> (In reply to Jon Doane from comment #159)
> > I've literally been doing:
> > "echo  high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
> > every day to boot my machine for over a year
> 
> See comment 55 if your system is running systemd, you can use this service:
> 
> https://github.com/illwieckz/dpm-query/
> 
> It will do it for you at startup, it's painless and I'm using it since 19
> months without any issue.

This sounds a lot like what I've been doing manually which sounds nice. Thanks
for the input. I honestly would like a solution that doesn't cause my machine
to draw an additional 90 watts at idle though. As I said, I've been doing this
for well over a year now and I'd prefer a solution, not a hack, considering how
old this issue is.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Thomas DEBESSE  changed:

   What|Removed |Added

 Attachment #134125|0   |1
is obsolete||

--- Comment #169 from Thomas DEBESSE  ---
Created attachment 134127
  --> https://bugs.freedesktop.org/attachment.cgi?id=134127=edit
kernel patch: set "high" default DPM level instead of "auto" for 0x67B0/0x67B1
variants

Sorry, there was a stupid typo in the patch, this is now fixed.

I'm running on that code and it works.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Thomas DEBESSE  changed:

   What|Removed |Added

 Attachment #134124|0   |1
is obsolete||

--- Comment #168 from Thomas DEBESSE  ---
Created attachment 134125
  --> https://bugs.freedesktop.org/attachment.cgi?id=134125=edit
kernel patch: set "high" default DPM level instead of "auto" for 0x67B0/0x67B1
variants

So, I had to wait two hours, but I got the crash on my 0x67B0 variant too. It's
still better than two years ago when it happened some seconds after X spawning,
but it's still there. So I updated my patch to make the trick for these two
variants.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #167 from Thomas DEBESSE  ---
Created attachment 134124
  --> https://bugs.freedesktop.org/attachment.cgi?id=134124=edit
kernel patch: set "high" default DPM profile instead of "auto" for 0x67B1
variant

So, using my 0x67B0 variant, new firmware and "auto" profile I was able to run
the vkQuake Vulkan game, the Unvanquished OpenGL game, the Unigine
Superposition OpenGL benchmark, the Luxmark Hotel OpenCL benchmark, and did
some OpenCL tasks with Darktable photo software. In fact in the past, just
running Gnome Shell (even the one run by GDM) was enough to take down the
computer.

I remember having tried the "auto" profile with new firmware in the past but I
had to to return to "low" or "high" profile because at this time the firmware
update just made the hang less immediate, but the hang was still happening
randomly, it was just happening lately. The bug appears to now be gone on my
end.

Everything looks fine on my 0x67B0 variant so it looks like the firmware and
some kernel updates did the trick for me (I'm now running Linux 4.12).

So, the only remaining variant known to be faulty is the 0x67B1 one.

So forget what I've said about the MSI 39 390X, it's now a model known to work.

Since the only affected model looks to be the 0x67B1 variant, I wrote this
small patch that must set "auto" as DPM profile on AMD GPU except for the
0x67B1 HAWAII variant which will use "high" as default. This patch does not
prevent the user to force the "auto" DPM profile by itself, but the "high" one
must now be set by default on this known variant.

I'm not able to test this patch since my GPU is the 0x67B0 one and looks to not
be affected by the bug anymore.

Before testing this patch, please check that you have the latest firmware for
your card. If not, update your firmware first as explained in previous comments
and check if it fixes the issue for you. If the latest firmware and a recent
kernel is not enough for you, well, perhaps we will have to mainline this
kernel change if AMD is not able to provide a fix.

This patch targets the 4.12 kernel tree but is so simple it must work on some
other versions too.

A review by someone at AMD like Marek Olšák, Alex Deucher or John Bridgman who
had participated in that thread would be very appreciated.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #166 from garththei...@hotmail.com ---
As does mine, my dmesg ...

[drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1682:0x9390
0x80).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #165 from Thomas DEBESSE  ---
Note that all joined dmesg reports a HAWAII 0x1002:0x67B1 PCI ID except mine
reporting a HAWAII 0x1002:0x67B0 PCI ID (I also checked the dmesg joined in
duplicates of this bug). So the subset seems to be well known.

In fact I haven't checked in a while if my GPU is still affected or not, I
remember some firmware could change things. I will recheck, if my GPU works on
auto, it means only 0x67B1 would be affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #164 from Thomas DEBESSE  ---
(In reply to Jon Doane from comment #159)
> I've literally been doing:
> "echo  high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
> every day to boot my machine for over a year

See comment 55 if your system is running systemd, you can use this service:

https://github.com/illwieckz/dpm-query/

It will do it for you at startup, it's painless and I'm using it since 19
months without any issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #163 from Thomas DEBESSE  ---
> It seems tied to a small subset of 390s.

Many precise models were listed. It's easy to get one of them.
For example this one is known to be buggy:
https://www.amazon.com/dp/B00ZGF158A/

It's weird if AMD developers can't put their hand on AMD hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #162 from Chris Waters  ---
One of the issues I've seen mentioned by one of the AMD guys on Reddit
(/u/bridgmanAMD) is that they have been unable to reproduce the issue.  It
seems tied to a small subset of 390s.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #161 from garththei...@hotmail.com ---
Not sure how well a bug bounty might work for this issue, but would there be
any interest? Maybe a fund for hardware purchase (R9 390) to send to someone
with the expertise to diagnose/fix work against. 

I'm willing to chip in with the hope of seeing some progress and resolution.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #160 from Stefan  ---
Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #159 from Jon Doane  ---
Is there going to be any work on this? I've literally been doing:
"echo  high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
every day to boot my machine for over a year hoping that this might get fixed
but, I've seen practically no progress made on this bug. After attempting to
use kernel 4.13, it becomes unstable and crashes faster than I can duck out
into a TTY so, it's almost like the problem is getting worse as time goes on.
This is literally a crippling bug and I find it astonishing that something,
like locking VRAM clocks and making 500Mhz the minimum core clock for all 390s
hasn't been implemented as a stopgap measure to at least get the thing stable.
For crying out loud, this bug has been open for 2 years now and has been
reproduced by several different people, or do we have to wait another 2 years
before we're told that it won't be fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #158 from janweber...@gmail.com ---
asus strix 390 owner.

gentoo kernel 4.12.3 and amdgpu 1.3.0.


get crash after 10-30seconds dwm.

only think that helps: "echo  high >
/sys/class/device/drm/card0/power_dpm_force_performance_level" but you have to
do this everytime the system start and before launch xserver.


i found this here (at bottom):
https://wiki.archlinux.org/index.php/AMDGPU

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #157 from j...@dev1ce.com ---
https://bugs.freedesktop.org/show_bug.cgi?id=101377

this has been open for about a month with no activity.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #156 from John Bridgman  ---
#155 sounds like a completely different problem - j...@dev1ce.com can you
please start a new ticket ? Please indicate in that ticket whether this is a
regression (worked before, stopped working when you did ) or a system that
has never worked ?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #155 from j...@dev1ce.com ---
Running a gigabyte AMD R9 380 card and getting similar problems.

the system boots, loads the driver and the fans briefly spin to 100% before the
video goes completely dark and the monitor turns off.  the card is detected as
a Tonga PRO 285/380.  

this issue is going to become much more critical in the next week, as SteamOS
just switched their AMD proprietary drivers for amdgpu open source drivers.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #154 from gsc_m...@yahoo.com ---
R9 390 owner here. Just replaced my old Ubuntu 14.04 + fglrx with Fedora 25,
then 26 + Mesa and hit this problem as well. It took me a lot of fiddling and
searching to understand why my 3 years newer system has become unusable.

The only thing that worked for me was radeon.dpm=0 but, well, (expletive), my
400€ card has been reduced to a 40€ card thanks to this.

I can report that I tried #115 and it didn't solve it for me. What it did
though, was to delay the crash from 10 seconds to about one 30-60 seconds (I'm
getting a full hard crash with black screen, dead I/O, all fans maxing out,
regardless of what I'm doing, if I'm fast I can get to run Unigine Valley for a
bit, if I don't then it can crash while desktop is sitting idle).

I'm not very Linux-handy, but if anybody needs my system as a guinea pig for
hopefully solving this, please let me know, I'm willing to help.

And if someone has knowledge whether a fix is (still) under work, please update
us here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #153 from garththei...@hotmail.com ---
I too have toggled my TPD switch (XFX R9 390) and continue to get black screen
freeze at non-deterministic times with a non-stressful workload. Running 4.11.1
with the latest git firmware (radeon).

My work-around is to set the power_dpm_force_performance_level and the black
screen behaviour is mitigated.

Let me know if I might assist in any way collecting logs etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #152 from Alfredo Mendez  ---
(In reply to Marek Olšák from comment #151)
> Alfredo, did you try to switch the TDP switch on the side of the card?

Yeah, and the system eventually was hit with a blackscreen.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #151 from Marek Olšák  ---
Alfredo, did you try to switch the TDP switch on the side of the card?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #150 from Alfredo Mendez  ---
I have an ASUS Strix R9 390 and attempted to get it to work, in a nutshell for
those looking for redemption... it didn't work.

I tried to switch drivers from radeon to amdgpu, and both equally fail
randomly. Setting the DPM to zero reduces the chances of black screening, but
expect to encounter them either way. Simply put, the drivers are still bad for
the 390's.

This bug is about to become three years old, and while 17.04 already came out
with the same issue, this should be set to its highest level, its been long
overdue with no real progress. I would love to collaborate in fixing this
issue, but I am simply below the average linux user standard.

I hope more people can volunteer in finding the culprit, but for now it points
out to be more power related.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #149 from alvarex  ---
I forgot to mention I had a similar problem on Windows also with a 260x on the
same motherboard so I think in my case is something to do with the motherboard.
I tried modyfing some option in grub but that did't help, I added

iommu=pt acpi_osi=Linux acpi=force acpi_enforce_resources=lax
acpi_osi='!Windows 2013' acpi_osi='!Windows 


The iommu table is bugged on this motherboard maybe it has something todo? If I
disable iommu completely on the bios usb devices will not power up.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #148 from alvarex  ---
(In reply to Chris Waters from comment #133)
> I decided to record how my system behaves when using Linux and my 390
> together.
> 
> This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk
> 
> This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all
> graphically intensive. On KDE Plasma 5 it's even worse, my entire system
> will sometimes crash. It's completely unusable and I'm stuck on Windows
> because of this.
> 
> ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. I
> tried loading one to see what would happen if I tried something a bit
> intensive, but my entire system crashed. Ended up having to restart
> recovered my session in Firefox.
> 
> This look the same for other 390 users?

thanks for the video maybe I should open another bug, I have the same artifacts
with a rx460. It happens randomly when resuming from standby, similar symptoms
as described in this bug. I will try patching the kernel and disabling some dpm
features as suggested, I'm not sure if it started happening with 4.9 or 4.10.
Setting power_dpm_force_performance_level to manual or high doesn't work.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #147 from John Boero  ---
Would love to see this get pushed through.  Frustrating having to manually
build kernels each release.  It looks like history of the Fedora kernels has
this being disabled and re-enabled by default a few times.  Much easier to
blacklist a module than have to build a whole new kernel every time.  My $0.02

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #146 from Marek Olšák  ---
All Hawaii cards should have a TDP switch on the side of the card. Can you flip
the switch when the computer is powered off and do the testing again. You can
google some info about that switch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #145 from Harald Judt  ---
You are certainly right and the files differ, so I assume it could be a problem
with the firmware. But since amdgpu works fine for me now, I will simply use
this and bother no longer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #144 from Michel Dänzer  ---
(In reply to Harald Judt from comment #143)
> With radeon, DPM still fails to resume properly for the 390 after hibernation.

Make sure the bonaire_uvd.bin firmware file is up to date, see bug 98988.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #143 from Harald Judt  ---
I have merged
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.10-wip into 4.9 and
am now using amdgpu with the r9 390, and everything works great so far except
that the cursor is no longer visible after hibernating and resuming, but
switching to SWCursor resolves this, so this is a viable workaround. I will
open another bug for this, but it is only a minor issue for me. With radeon,
DPM still fails to resume properly for the 390 after hibernation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #142 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #141)
> At what point did we go from talking about radeon, the driver this bug
> report is about, to amdgpu?

This freedesktop.org bug is a Mesa bug. The bug title is "Radeonsi ...".

If the visual artifacting issue is solved in radeon.ko, the patch will probably
be in short time applied to amdgpu.ko, and vice versa.

> Isn't support and performance for GCN 1.1 cards rather bad on amdgpu
> compared to radeon?

Support for R9 390/390X (Grenada) in amdgpu.ko is basically equivalent to
radeon.ko (at least on my machine). Performance is very similar too.

amdgpu.ko and radeon.ko are loading the same firmware files for R9 390/390X
(/lib/firmware/radeon/{hawaii,HAWAII}*.bin).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #141 from Chris Waters  ---
At what point did we go from talking about radeon, the driver this bug report
is about, to amdgpu?

Isn't support and performance for GCN 1.1 cards rather bad on amdgpu compared
to radeon?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #140 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #139)
> Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers.
> No pp_dpm_sclk in either.
> 
> Am I missing something?

Manjaro (both stable and development) is running on Linux kernel 4.4.

Ubuntu MATE 16.10 is running on Linux kernel 4.8.0, but it has
CONFIG_DRM_AMDGPU_CIK disabled in kernel configuration and is loading radeon.ko
instead of amdgpu.ko.

The following 3 commands can be used to check whether amdgpu+CIK are enabled:

$ uname -r
4.8.0 (or later version)

$ lsmod | grep amdgpu
amdgpu

$ zgrep CIK /proc/config.gz
CONFIG_DRM_AMDGPU_CIK=y

An alternative form of the last command:

$ grep CIK /boot/config-$(uname -r)
CONFIG_DRM_AMDGPU_CIK=y

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #139 from Chris Waters  ---
Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers. No
pp_dpm_sclk in either.

Am I missing something?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #138 from Chris Waters  ---
Update:

Finally had time to boot a liveCD (Ubuntu MATE 16.10) and try this all out.

I have multiple card listings in /sys/class/drm, but only one that is a card#
folder (ie card0), the rest are all variations on card0 plus  port type (eg
card0-HDMI-A-1).

I have no pp_dpm_sclk in /sys/class/drm/card0/device/ so I'm unable to do the
first command.

I have power_dpm_force_performance_level and I was going to at least try
setting it to manual just to see, but echo says "write error: Invalid argument"
when doing it as root and bash complains about lack of permissions when not
root (sudo makes no difference).

Mesa version is 12.0.3, so I'm grabbing Manjaro since that is running on Mesa
13 and will test there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #137 from Thomas DEBESSE  ---
(In reply to Chris Waters from comment #136)
> Can this be done without rebooting?  I'd like to test this on a liveCD
> since, as I've said, I'm currently stuck on Windows. The idea of needing to
> install a distro just to test this is a bit unappealing to me.

It's not only it can, it must be done without rebooting, stuff in /sys are live
settings, even on installed distro, you must expect to lose them on reboot,
it's a fake file system, writing there does not write something on your hard
disk, reading and writing there is just reading and writing bits in memory with
a file system view for convenience.

Beware, there is a little mistake in Jan Ziak's directives (missing a leading
slash before “sys”), this is ok:

$ echo manual > /sys/class/drm/card1/device/power_dpm_force_performance_level
$ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk

Do that *and do not reboot* or you'll lose the changes so you will never test
them. The way to test them is to apply these changes at runtime and doing stuff
without rebooting. If you reboot you'll lose the change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #136 from Chris Waters  ---
Can this be done without rebooting?  I'd like to test this on a liveCD since,
as I've said, I'm currently stuck on Windows. The idea of needing to install a
distro just to test this is a bit unappealing to me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #135 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Jan Ziak from comment #134)
> (In reply to Chris Waters from comment #133)
> > I decided to record how my system behaves when using Linux and my 390
> > together.
> > 
> > This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk
> > 
> > This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all
> > graphically intensive. On KDE Plasma 5 it's even worse, my entire system
> > will sometimes crash. It's completely unusable and I'm stuck on Windows
> > because of this.
> > 
> > ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. 
> > I
> > tried loading one to see what would happen if I tried something a bit
> > intensive, but my entire system crashed. Ended up having to restart
> > recovered my session in Firefox.
> > 
> > This look the same for other 390 users?
> 
> The video is similar to what I am seeing, in the video it is more severe.
> 
> 
> 
> If the following commands are executable on your machine:
> 
> $ ls -d /sys/class/drm/card?
> /sys/class/drm/card0  /sys/class/drm/card1
> 
> $ cat /sys/class/drm/card1/device/pp_dpm_sclk
> 0: 300Mhz *
> 1: 500Mhz 
> 2: 698Mhz 
> 3: 858Mhz 
> 4: 899Mhz 
> 5: 935Mhz 
> 6: 969Mhz 
> 7: 1000Mhz
> 
> then (question) does the flickering go away if you run:
> 
> $ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk

Correction:

$ echo manual > sys/class/drm/card1/device/power_dpm_force_performance_level
$ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #134 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #133)
> I decided to record how my system behaves when using Linux and my 390
> together.
> 
> This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk
> 
> This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all
> graphically intensive. On KDE Plasma 5 it's even worse, my entire system
> will sometimes crash. It's completely unusable and I'm stuck on Windows
> because of this.
> 
> ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. I
> tried loading one to see what would happen if I tried something a bit
> intensive, but my entire system crashed. Ended up having to restart
> recovered my session in Firefox.
> 
> This look the same for other 390 users?

The video is similar to what I am seeing, in the video it is more severe.



If the following commands are executable on your machine:

$ ls -d /sys/class/drm/card?
/sys/class/drm/card0  /sys/class/drm/card1

$ cat /sys/class/drm/card1/device/pp_dpm_sclk
0: 300Mhz *
1: 500Mhz 
2: 698Mhz 
3: 858Mhz 
4: 899Mhz 
5: 935Mhz 
6: 969Mhz 
7: 1000Mhz

then (question) does the flickering go away if you run:

$ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #133 from Chris Waters  ---
I decided to record how my system behaves when using Linux and my 390 together.

This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk

This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all
graphically intensive. On KDE Plasma 5 it's even worse, my entire system will
sometimes crash. It's completely unusable and I'm stuck on Windows because of
this.

¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. I
tried loading one to see what would happen if I tried something a bit
intensive, but my entire system crashed. Ended up having to restart recovered
my session in Firefox.

This look the same for other 390 users?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #132 from Filip Brygidyn  
---
I am experiecing the same freezes on my updated arch box (kernel 4.8.11-2, mesa
13.0.2-2) with my MSI R9 390.
Without radeon.dpm=0 I observe the following:
- I can get into and stay in tty with no crashes
- I experience wierd filckering/'image jumping'. (Not artifacts)
- With 2 monitors connected the mentioned flickering is unbearable and the
image jumps so much it's hard to see anything. (and it gets worse over time)
- After I start a window manager (xfce in my case) the system will freeze at
the moment I cause any major load. This would support the ongoing suspition
that the problem may be caused by clock or voltage changes.

With radeon.dpm=0 I am yet to crash a single time in the similar way.

This may be unrelated but I experience similar (although much less frequently
occuring) crashes under windows.
The system would run perfectly fine under load or idle for a long time but when
the load is changing the system sometimes freezes or crash with a BSOD.
Good example would be when I am running a game and I alt-tab a lot, changing
the load drasticaly from 100% to idle and back. That is the moment when crashes
occur most frequently.


I am yet to try other firmware, mclk or other suggestions mentioned in here.
Will post when I get enough time and motivation to tinker...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #131 from Harald Judt  ---
I do not have problems so far except there are sometimes red pixels flickering
on screen. Still need to investigate why that happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #130 from Chris Waters  ---
This bug has been marked as 'critical' for over a month now, has there been any
work on this in that time?

The bug seems related to the shader clock, possibly the driver isn't setting
correct values?  Has anyone checked to see if the driver is properly setting
the clock?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #129 from Chris Waters  ---
> If I disable the lowest 300 MHz shader clock, so that the minimum shader
> clock is 500 MHz and maximum is 1000 MHz, the flickering disappears.

What about lower settings than 500 MHz?  Did you try 400 MHz or even 350?

What is the performance like?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #128 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #127)
> Second question, is there any way to just force the memory clock to stay at
> 1500MHz? If the bug is caused by memory switching (and not the memory being
> clocked way too high), then forcing the memory to stay at the max standard
> clock should give us the stability of 150MHz.

Some months ago, I thought it was just mclk switching. But today I am not so
sure about it.

Executing the following steps on my machine with an R9 390:

- lock mclk to 1500MHz
- start playing Mad Max via Steam
- switch to the game map via gamepad or keyboard
(https://www.google.sk/search?q=mad+max+game+map=isch)

results in noticeable screen image flickering.

If I disable the lowest 300 MHz shader clock, so that the minimum shader clock
is 500 MHz and maximum is 1000 MHz, the flickering disappears.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #127 from Chris Waters  ---
I've noticed that on my Win7 install if I up the memory clock a good (1700MHz+)
bit I'll get the same exact artifacts as I would in Linux. Maybe the driver is
trying to switch to too high of a clock for memory?

Second question, is there any way to just force the memory clock to stay at
1500MHz? If the bug is caused by memory switching (and not the memory being
clocked way too high), then forcing the memory to stay at the max standard
clock should give us the stability of 150MHz.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed:

   What|Removed |Added

   Severity|major   |critical

--- Comment #126 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
Resolution of this bug is critical for CONFIG_DRM_AMDGPU_CIK to move from
experimental to non-experimental state.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #125 from Christoph Seifert  
---
For me switching power states does also result in a system freeze. With
radeon.dpm = 0 everthing is working properly but slowly. If I switch manually
to another power profile (e.g. echo high >
/sys/class/drm/card0/device/power_profile) I got a freeze likewise. With
radeon.dpm = 1 the freeze happens after a few seconds of video playback or some
other load, ergo if the card changes its power profile.

The work around (k firmware) from comment #115 does not work for me. Same
behaviour as without.

So I tried disabling specific DPM features as suggested by Alex Deucher in
comment #60. Disabling mclk (pi->mclk_dpm_key_disabled = 1) does the trick for
my card but the performance is similar to the radeon.dpm = 0 kernel parameter.

With radeon.dpm = 1 and only mclk disabled, the sclk (core clock) adjusts just
fine. High on load, low on no load. The mclk (memory clock) is just fixed at
150 Mhz.

So the freezes seems to be caused by switching memory clock.


Any hints for digging deeper?

My card is a MSI Radeon R9 390 too.
Linux Kernel 4.8.6
Mesa 13.0.0rc2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #124 from mail at marcelschaal.de ---
Created attachment 127648
  --> https://bugs.freedesktop.org/attachment.cgi?id=127648=edit
PowerColor R9 390 PCS+ vbios

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #123 from mail at marcelschaal.de ---
Still no luck with PowerColor R9 390 PCS+ on Fedora 25 (Kernel 4.8, mesa
12.0.3). Computer freezes after a few seconds. It seems to last a bit longer
with dpm=0, but less than 5-10 minutes. Attaching vbios since it was never
provided.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #122 from Lauri Gustafsson  ---
Seconded that 4.8 kernel on Arch has fixed the unstability. Still getting
rather bad artifacts from time to time because of the dynamic memory clock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #121 from emilio.moretti at gmail.com ---
Finally working:
I just upgraded to ubuntu 16.10  (kernel 4.8.0-22-generic) and I've been using
the pc all day long without problems (this was impossible before).
I had to use the kernel parameter radeon.dpm=0 in grub in order to get a stable
desktop, and I can confirm I don't need it any more.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #120 from DesiOtaku  ---
I hate to "me too" here, but I can confirm that the steps outlined in comment
#115 does not resolve the problem. However, the
power_dpm_force_performance_level and power_dpm_state trick outlined in comment
#29 does prevent it from freezing.

I have a ASUS Radeon R9 390X running Kubuntu 16.04. I am willing to test out
any potential fixes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #119 from PhilipW  ---
I also suspect this - microcode does not fix the issue on a Powercolor r9 390
pcs+.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #118 from pc.jago1337 at gmail.com ---
Using radeon, the microcode 'fix' doesn't fix the problem for me. Perhaps there
are multiple bugs, and not just the one?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #117 from Yuxuan Shui  ---
This _k firmware seems to fix the problem for me as well (have been running
without lockup for a while), but only with the radeon driver. With amdgpu, I
still got lock ups, though less often.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #116 from Calico Bass  ---
I found this bug report because I was having problems extracting my vbios and
parsing the extracted rom. I notice that all the vbios.rom files attached here
are 64K.

When parsing my rom I found it was truncated to 64K. A coincidence or a symptom
of an unrelated or related problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #115 from Jonas  ---
I'll try to sum up, to help a little if some people are confused about the
process of "workarounding" it.


1) Go here: https://people.freedesktop.org/~agd5f/radeon_ucode/hawaii
2) Download every file.
3) Go here https://people.freedesktop.org/~agd5f/radeon_ucode/k/
4) Download hawaii_k_smc.bin
5) Rename this file to hawaii_smc.bin (to replace the one you have from step 2)
6) Put all those files in your "firmware" folder (in my case
/usr/lib/firmware/radeon), make a backup of those before, if you want.
7) Reboot & enjoy.

For some people it seems necessary to update initrd, but in my case (Arch
Linux), only a reboot gives me good DPM support and it almost never crashes. On
every firmware update on your system, you might have to repeat all the steps
(until those files are used on your distro by default).

I hope it is somewhat easier to get it working.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

pc.jago1337 at gmail.com changed:

   What|Removed |Added

   Severity|minor   |major
   Priority|medium  |high

--- Comment #114 from pc.jago1337 at gmail.com ---
This bug really should be marked as MAJOR, seeing as how it literally runs the
same as or worse than the R9 270X, which is something like $200 cheaper.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #113 from John Bridgman  ---
Yep, agree. Will see if I can get that documented. Thanks !!

From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
bugzilla-daemon at freedesktop.org
Sent: Tuesday, July 19, 2016 11:23 PM
To: dri-devel at lists.freedesktop.org
Subject: [Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable
and poorly performing

Comment # 112<https://bugs.freedesktop.org/show_bug.cgi?id=91880#c112> on bug
91880<https://bugs.freedesktop.org/show_bug.cgi?id=91880> from Chris
Waters<mailto:doublebytegames at gmail.com>

> Yep, that's a fair point. I was just trying to make sure we were collecting

> good data. Thanks.



I'm more than willing to help test, just need directions. Having everything

split up over all these comments is messy and makes this nigh impossible to

figure out for those not familiar with the process.


You are receiving this mail because:

  *   You are the assignee for the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/6760ef07/attachment.html>