Comment # 173
on bug 91880
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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
