From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0" Date: Fri, 25 Mar 2016 06:41:52 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0493698530==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id DEE7D6E1E1 for ; Fri, 25 Mar 2016 06:41:51 +0000 (UTC) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0493698530== Content-Type: multipart/alternative; boundary="14588881110.9FfBc.1007"; charset="UTF-8" --14588881110.9FfBc.1007 Date: Fri, 25 Mar 2016 06:41:51 +0000 MIME-Version: 1.0 Content-Type: text/plain https://bugs.freedesktop.org/show_bug.cgi?id=94692 Bug ID: 94692 Summary: Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0" Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: nchlsvaughan@gmail.com 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 -- You are receiving this mail because: You are the assignee for the bug. --14588881110.9FfBc.1007 Date: Fri, 25 Mar 2016 06:41:51 +0000 MIME-Version: 1.0 Content-Type: text/html
Bug ID 94692
Summary Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
Product DRI
Version unspecified
Hardware x86-64 (AMD64)
OS Linux (All)
Status NEW
Severity major
Priority medium
Component DRM/Radeon
Assignee dri-devel@lists.freedesktop.org
Reporter nchlsvaughan@gmail.com

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


You are receiving this mail because:
  • You are the assignee for the bug.
--14588881110.9FfBc.1007-- --===============0493698530== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0493698530==--