mmm further tests shown the oops was casual, maybe related to the real 
problem, I can't say. I'm unable to reproduce it.

But the gpu stall is 100% reproducible with dpm enabled. Attached is the log 
that usually shows up. Other than that, I also observe the lspci "Unknown 
header type 7f" problem similar to ko bug #73041
https://bugzilla.kernel.org/show_bug.cgi?id=73041

A few notes:

- I can confirm that the problem was first introduced by 
6c7bccea390853bdec5b76fe31fc50f3b36f75d5. Until 
e14cd2bbcb98541e199b7223f38d61527dfe45c9 the gpu works.

- The "Unknown header type 7f" thing is not new to me. I experienced this 
problem a year ago, trying the Catalyst driver. I spent some time filing a bug 
report for amd, which remained unanswered:
http://ati.cchtml.com/show_bug.cgi?id=743

Alex, do you have any clue? Maybe your commit changed something into the 
initialization order which is confusing this gpu?

Thanks,

Giancarlo


In data luned́, aprile 14, 2014 12:57:55, Giancarlo Formicuccia ha scritto:
> Greetings,
> 
> I'm facing a dpm regression in 3.14 on my radeon TURKS (pci id 1002:6840).
> Upon loading the radeon module with dpm enabled, the screen goes black and
> the computer locks up.
> 
> The problem first appeared at 6c7bccea390853bdec5b76fe31fc50f3b36f75d5
> drm/radeon/pm: move pm handling into the asic specific code
> 
> and is still present in 3.15-rc1.
> 
> Loading the radeon module with dpm disabled works.
> 
> I captured the relevant kernel messages using a netconsole (attached); there
> is an oops in radeon_ring_write presumibly during the test of ring #5.
> 
> Thanks,
> 
> Giancarlo