Bug 94692 - Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
Summary: Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dp...
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-25 06:41 UTC by Nicholas Vaughan
Modified: 2016-03-25 18:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
fix (1.13 KB, patch)
2016-03-25 14:33 UTC, Alex Deucher
no flags Details | Splinter Review

Description Nicholas Vaughan 2016-03-25 06:41:52 UTC
Specific card: "SAPPHIRE Radeon™ Dual-X R7 370 2G D5"

When booting with radeon.dpm=0, setting the power_method to "dynpm" (from the default of "profile" appears to do nothing.
Without changing anything after booting, /sys/kernel/debug/dri/0/radeon_pm_info reports absurdly low memory and engine clock rates.
echo'ing "low" or "mid" to /sys/class/drm/card0/device/power_profile causes the clock rates to rise slightly, but still to nowhere near what radeon_pm_info reports the card to be capable of (whether I echo "low" or "mid" does not seem to matter-- they have the same effect on the clocks). After changing the power_profile, changing it to "high", "auto", or even back to "default" causes the system to immediately hang.



After seeing Elia Argentieri's success with adding a line to the dpm quirk's array [1], I decided to see if doing something similar would resolve my problem.

From /var/log/Xorg.0.log's
(--) PCI:*(0:1:0:0) 1002:6811:174b:2015 rev 129, Mem @ 0xe0000000/268435456, 0xf7e00000/262144, I/O @ 0x0000e000/256, BIOS @ 0x????????/131072
line, I presume that my card's specific chip_device, subsys_vendor, and subsys_device are 0x6811, 0x174b, and 0x2015, respectively. As I did not see this set of identifiers listed in the "si_dpm_quirk_list" array in drivers/gpu/drm/radeon/si_dpm.c in kernel 4.4.6 [2], nor in kernel 4.5 [3], I decided to try my hand at compiling the kernel myself.

First I compiled the kernel (4.4.6) without modification as a control, to ensure that if I made a modification which caused DPM to work as intended, it was the modification which had fixed the problem. This kernel, as expected, would hang if not booted with the either of the kernel parameters "nomodeset" or "radeon.dpm=0".
Then, I added the same line that Elia added to the quirks array, changing only the identifiers specific to my card. Specifically, I added the following line to the quirks array:
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0x2015, 0, 120000 },
Upon compiling, installing, and running the kernel, I found that it booted without "nomodeset" or "radeon.dpm=0", and that DPM actively raised the engine clock to its quoted maximum (985MHz) at power level 4, and raised the memory clock to its quirk-limited maximum of 1200MHz at power level 1 and above, while keeping the clocks down to 300MHz and 150MHz respectively at power level 0 with no noticeable degradation of desktop performance.

I would very much like to get this quirk included in the Linux kernel source so that I do not have to manually compile my own kernels. If there is *any* further information I can provide to ensure that this happens, please let me know and I will try to respond as quickly as possible. Elia's quirk seems to have been entirely ignored, and this does not bode well for the quirk my card requires.

Your swift reply is appreciated,
Nicholas

[1] https://bugs.freedesktop.org/show_bug.cgi?id=91294
[2] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/radeon/si_dpm.c?id=refs/tags/v4.4.6#n2925
[3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/si_dpm.c?id=refs/tags/v4.5#n2925
Comment 1 Elia Argentieri 2016-03-25 08:02:34 UTC
Hi, my quirk was included in Linux [1]. In fact from Debian's kernel 4.4 it successfully boots without having to recompile.

Sadly performance are NOT worth the price of the product. I still prefer my older HD 6670 with 2GB VRAM which gives me much more stable fps. With R7 370, Xonotic is almost unplayable because of stuttering even with lowest settings.
Also after almost an year I see no progress on this front. They included the quirk and nothing more. I still have to understand why all this happens in the first place! What kind of black magic is Catalyst doing? Why can't we do the same?

These are my two cents,
Elia

[1]: https://github.com/torvalds/linux/commit/e71c1b9261d627677590f61273dddc0e87eb6a7e
Comment 2 Nicholas Vaughan 2016-03-25 08:21:22 UTC
(In reply to Elia Argentieri from comment #1)
> Sadly performance are NOT worth the price of the product. I still prefer my
> older HD 6670 with 2GB VRAM which gives me much more stable fps. With R7
> 370, Xonotic is almost unplayable because of stuttering even with lowest
> settings.

Elia,
First of all, wonderful to hear from you that your kernel patch was included! Secondly, the primary graphics load that I put on my desktop is running DotA 2, which runs *phenomenally* now that I have added this quirk-- with one caveat; that caveat being that loading un-seen models (or something like that?) causes stuttering the first time that they are seen. Fortunately, the fix for this, in this game, is trivial: drag the camera view as rapidly as possible over the entire map at the beginning of my first match of the day (this take 2~3 seconds). And by phenomenally, I mean that i got 20~40 fps before adding this quirk, with all options off other than texture quality being on high, and now I get a consistent 60fps with all settings turned on (global lighting, specular, additive lighting pass, etc., etc.), shadow settings on ultra (instead of off), vsync, and anti-aliasing (I assume it is 2x AA).

In short, to me, adding this quirk is an incredible boon, removes any desire I've ever had to use Catalyst (yuck.), and I'm just thrilled to have it. I'd like to thank you personally, Elia, because your bug report was the first I saw which was short enough for me to read, but showed a solution to a problem that I've had for ages.

With all of my thanks,
Nicholas


P.S.: Perhaps you, or someone else (not really sure who does what around here) should change the status of your bug from "NEW" to "RESOLVED", possibly with a comment on which kernels now support the quirk? :)
Comment 3 Alex Deucher 2016-03-25 14:33:24 UTC
Created attachment 122546 [details] [review]
fix

The attached patch will be applied upstream and onto the stable kernel series.
Comment 4 Nicholas Vaughan 2016-03-25 18:49:29 UTC
(In reply to Alex Deucher from comment #3)
> Created attachment 122546 [details] [review] [review]
> fix
> 
> The attached patch will be applied upstream and onto the stable kernel
> series.

Thank you very much.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.