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

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2285 bytes --]

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

--- Comment #173 from Thomas DEBESSE <dev@illwieckz.net> ---
(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.

[-- Attachment #1.2: Type: text/html, Size: 3376 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel