Bug 83731 - dpm still not working on radeon TURKS 1002:6840
Summary: dpm still not working on radeon TURKS 1002:6840
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-02 06:19 UTC by Giancarlo Formicuccia
Modified: 2016-03-23 18:54 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.17-rc
Subsystem:
Regression: No
Bisected commit-id:


Attachments
kernel messages with dpm enabled (41.66 KB, application/octet-stream)
2014-09-02 06:19 UTC, Giancarlo Formicuccia
Details

Description Giancarlo Formicuccia 2014-09-02 06:19:22 UTC
Created attachment 149011 [details]
kernel messages with dpm enabled

Now that dpm is enabled by default on TURKS cards, I'd like to give another try to get it working on my card.

Booting a 3.17-rc3 kernel results in a blank screen; the computer is not locked up, I still can ssh into the machine and grab the kernel messages.

lspci reports:

01:00.0 0300: 1002:6840 (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: radeon
        Kernel modules: radeon

01:00.1 0403: 1002:aa90 (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel modules: snd_hda_intel

Loading the radeon module with dpm=0 works without problems.

Note that dpm *did* work correctly until 3.13 kernels (using dpm=1); then it broke during the 3.14 delopement cycle. I bisected the bad commit in 6c7bccea390853bdec5b76fe31fc50f3b36f75d5
drm/radeon/pm: move pm handling into the asic specific code
and reported the problem on the dri-devel ml, without luck.
My guess is that something changed during the initialization of the card which is confusing this GPU, but I was unable to identify the problem by myself.

Attached the kernel messages after loading the radeon module on 3.17-rc3.
Comment 1 Giancarlo Formicuccia 2014-10-10 07:13:03 UTC
Kernel 3.17 is out and now radeon.dpm=0 is required in order to boot this system.

Can I receive a comment about this problem? Why is this card special?
Comment 2 Alex Deucher 2014-10-13 16:50:45 UTC
Does it work properly with radeon.runpm=0
Comment 3 Giancarlo Formicuccia 2014-10-14 07:16:38 UTC
No runpm=0 doesn't help.

I read from your comments on 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 that the initialization order changed, and it's possibly related to my problem.

FWIW, (last time I checked, more than one year ago), fglrx seems to have a similar 'Unknown header type 7f' issue on this GPU. My bugreport on ATI bugzilla is here:
http://ati.cchtml.com/show_bug.cgi?id=743

Note You need to log in before you can comment on or make changes to this bug.