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

--- Comment #65 from Julian <jsbansen@gmail.com> ---
I've now tested the following configurations:

sclk_dpm_key_disabled = 0;
mclk_dpm_key_disabled = 0;
pcie_dpm_key_disabled = 0;
thermal_sclk_dpm_enabled = 0;
==> LOCKS UP - this is the default configuration

sclk_dpm_key_disabled = 1;
mclk_dpm_key_disabled = 1;
pcie_dpm_key_disabled = 1;
thermal_sclk_dpm_enabled = 1;
==> NO LOCKUP

sclk_dpm_key_disabled = 0;
mclk_dpm_key_disabled = 0;
pcie_dpm_key_disabled = 1;
thermal_sclk_dpm_enabled = 1;
==> LOCKS UP

sclk_dpm_key_disabled = 0;
mclk_dpm_key_disabled = 1;
pcie_dpm_key_disabled = 1;
thermal_sclk_dpm_enabled = 1;
==> LOCKS UP

sclk_dpm_key_disabled = 1;
mclk_dpm_key_disabled = 0;
pcie_dpm_key_disabled = 1;
thermal_sclk_dpm_enabled = 1;
==> NO LOCKUP - however, I periodically checked
/sys/kernel/debug/dri/0/radeon_pm_info and mclk never actually changed (always
150000). Maybe mclk usually always changes based on sclk? With slck locked,
mclk wouldn't change either, even if unlocked.




(In reply to Alex Deucher from comment #64)
> (In reply to Julian from comment #63)
> > At first I thought it was an issue with the writeback feature that caches
> > certain register values because it also caches an rptr value that is used in
> > the driver's gpu_lockup_check and is, to my knowledge, never actually
> > written to.
> 
> More likely it never gets written because the GPU has hung due to something
> else.

Sorry, I meant that I've searched the radeon source for the lines of code where
the value was accessed from. I've only found instances of it being read, no
instances of it being written to. But I won't put too much stock into that
since I hardly know the code base at all. I plan to mess with the code a little
now that I know how to compile single modules. If I find something substantial
that this might be a bug, I'll open a new issue about it.


> > 
> > Buuut using radeon.no_wb=1 doesn't help. So if I've found a bug it is not
> > the culprit of the lockups.
> 
> The no_wb option isn't really applicable on newer chips and most likely
> won't work.  Newer hw does not support the necessary features to not support
> wb.  It's mainly a leftover from the early radeons.

Thanks. Good to know.

-- 
You are receiving this mail because:
You are the assignee for the bug.