[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #25 from Alexandre Demers <alexandre.f.demers at gmail.com> ---
(In reply to comment #24)
> (In reply to comment #23)
> > Well, maybe the first thing would be to identify when or what sequence leads
> > to the hang. That's why I was suggesting to trace it. But if I understand
> > you correctly, you are saying the GPU is programmed once and then we just
> > move from state to another, right?
> > 
> > I'm not sure, but I think I've read somewhere it was possible to set a power
> > state manually, to force dpm to a given state in other words. Am I right?
> 
> A power state consists of several performance levels (generally 3 on cayman;
> low, medium, and high).  The driver loads a power state and then the GPU
> dynamically changes between the performance levels within that state based
> on GPU load.  You can force the GPU to always stay in the low or high state
> via sysfs.  See:
> http://www.botchco.com/agd5f/?p=57
> for more info.  That basically tells the GPU to stay in that performance
> level and to not dynamically transition between performance levels.

Thanks, I knew I had read it somewhere. You are confirming what I had
understood of the performance levels in a given state.

However, I'm thinking we are not looking at the right spot... I've been testing
power states and performance levels, running Youtube videos (which hitting in
the general GPU part, not UVD), playing videos with VLC (VDPAU enabled, which
was using UVD) and doing both at once. Everything was rock solid. Their must be
something else that has nothing to do with the power states. All performance
levels and transitions from one to another worked fine.

Is there something to your knowledge that could have more chance of hanging
when switching performance levels that would be less vulnerable with a fixed
mclk and vddci?

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