https://bugs.freedesktop.org/show_bug.cgi?id=72921
Priority: medium Bug ID: 72921 Assignee: dri-devel@lists.freedesktop.org Summary: DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33 Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: mmstickman@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa
As Linux kernel 3.13 has DPM now enabled by default, it is unbootable due to an issue with DPM and this set of hardware. Soon after the display is initiated, such as when it gets to the login screen, the system will simply power off and reboot if DPM is enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #1 from Alex Deucher agd5f@yahoo.com --- Please attach your xorg log and dmesg output with radeon.dpm=1 on the kernel command line in grub. While dpm is enabled by default, forcing dpm=1 will enable extra debugging output.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #2 from Alex Deucher agd5f@yahoo.com --- Created attachment 91047 --> https://bugs.freedesktop.org/attachment.cgi?id=91047&action=edit testing patch
Does the attached patch help? If so can you narrow down which options are causing the problem?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
Andreas Boll andreas.boll.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Mesa |DRI Version|git |unspecified Component|Drivers/DRI/R600 |DRM/Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #3 from Arno Schuring aelschuring@hotmail.com --- Created attachment 100359 --> https://bugs.freedesktop.org/attachment.cgi?id=100359&action=edit dmesg
Looks like I'm seeing this same issue with an A8-6500 and linux 3.14: the system reboots within a few seconds after the radeon module gets loaded. The motherboard is an MSI A78M-E45. I'm attaching my (netconsole-captured) dmesg, but no obvious errors are logged. Maybe the probed power states are off, I can't tell. It does look like netconsole mangled some of the output, hope it's still useful.
If I boot with radeon.dpm=0, everything seems fine (though I haven't run anything 3D yet, glxinfo output appears correct). Blacklisting the radeon module also prevents the system from rebooting, but X won't start.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #4 from Alex Deucher agd5f@yahoo.com --- Does attachment 91047 help?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #5 from Arno Schuring aelschuring@hotmail.com --- Hi Alex, just rebooted to test that patch. It applied to 3.15-rc8 with offset 6. Sadly, no change in behaviour. I've compared the power states in the dmesg logs, but they appear similar as well
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #6 from Kertesz Laszlo laszlo.kertesz@infobenefic.ro --- Cannot reproduce on A8-6500 with a Gigabyte F2A88X-D3H. I had a F2A85X-D3H before with a A8-5500, and i used kernels below and above 3.13 on that too, but never had this issue.
I compile the kernel and mesa regularly from git (base system is Debian Testing 64 bit), right now i have 3.15.0-rc7-00118-ga4bf79e installed and works without issues.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #7 from Collin nothingmuchheretosay@gmail.com --- I think this may apply to MSI hardware in general, because I have an FM2-A75IA-E53 Motherboard with an AMD A10-6700T and I can't boot without radeon.dpm=0 disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #8 from Alex Deucher agd5f@yahoo.com --- You might try a bios update if one is available for your board.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #9 from Collin nothingmuchheretosay@gmail.com --- (In reply to comment #8)
You might try a bios update if one is available for your board.
Just updated to the latest, no change, this bug NEEDS to get fixed sometime soon, hopefully? Maybe? How long does it normally take for bugs this bad to get fixed?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #10 from Kertesz Laszlo laszlo.kertesz@infobenefic.ro --- Since this bug seems to be restricted to specific boards, without your help will be hard to solve it.
You could try adjusting BIOS settings. Maybe you have some proprietary MSI specific "performance booster" settings or OC activated? Did you try resetting the BIOS to defaults? Do you have some special brand of memory?
Also, looking at that dmesg output i see some lines beginning with "#" such as
Jun 3 15:24:01 172.22.15.56 [ 51.381984] #011ui class: Jun 3 15:24:01 none etc.
I dont have any of those in my dmesg and never had (A8-5500 and A8-6500 APUs on Gigabyte boards).
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #11 from mmstickman@gmail.com --- If I recall correctly, I used AMD Radeon RAM when I built the system. I can't say whether or not the bug still occurs on the machine I posted this bug with because I built it as an office PC for someone else. Being a production machine, I didn't have any kind of boosters or overclocking features enabled. I think it's more than likely something to do with MSI's implementation of FM2/+
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #12 from Arno Schuring aelschuring@hotmail.com --- I have upgraded my bios from 25.1 to 25.3, issue remains. I will browse the BIOS for overclocking settings, but I didn't change any; so if they do effect this, then it's the factory-defaults causing this.
This is a wild guess, but the symptoms to me look like a spurious watchdog kicking in, given that the system appears fully functional right up until the reboot, no errors are logged and there is a delay between the modprobe and the reboot.
@Kertesz: according to Alex in comment #1, "forcing dpm=1 will enable extra debugging output". Possibly that's why you're not seeing those lines.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #13 from Kertesz Laszlo laszlo.kertesz@infobenefic.ro --- I DO have set radeon.dpm=1 in the kernel command line. Its there since this option was introduced (didnt remove it when it became default).
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #14 from Collin nothingmuchheretosay@gmail.com --- So what should I do with this? How long do I wait for a fix for this? I would really not want to replace my motherboard just to use my APU.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #15 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #14)
So what should I do with this? How long do I wait for a fix for this? I would really not want to replace my motherboard just to use my APU.
You can either disable dpm (I can add a quirk in the meantime to disable it by default for your board), or wait for the fix. I'm not sure how long it will take to track down exactly what is going wrong.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #16 from Alex Deucher agd5f@yahoo.com --- Created attachment 101179 --> https://bugs.freedesktop.org/attachment.cgi?id=101179&action=edit possible fix
Maybe there is some problem with the clocks or voltage in the highest power level. Does the attached patch help?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #17 from Collin nothingmuchheretosay@gmail.com --- (In reply to comment #16)
Created attachment 101179 [details] [review] possible fix
Maybe there is some problem with the clocks or voltage in the highest power level. Does the attached patch help?
Where and how do I apply this patch to... wherever it's supposed to go? And will it work on a Richland APU?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #18 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #17)
(In reply to comment #16)
Created attachment 101179 [details] [review] [review] possible fix
Maybe there is some problem with the clocks or voltage in the highest power level. Does the attached patch help?
Where and how do I apply this patch to... wherever it's supposed to go? And will it work on a Richland APU?
It applies to the kernel. You need to apply the patch and build and install the kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #19 from Alex Deucher agd5f@yahoo.com --- Created attachment 101191 --> https://bugs.freedesktop.org/attachment.cgi?id=101191&action=edit testing patch
Here's another kernel patch to try. Please try this independent of any other patches on this bug.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #20 from Collin nothingmuchheretosay@gmail.com --- (In reply to comment #19)
Created attachment 101191 [details] [review] testing patch
Here's another kernel patch to try. Please try this independent of any other patches on this bug.
First patch failed, gonna try out the second as soon as I start compiling a new kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #21 from Collin nothingmuchheretosay@gmail.com --- Second patch from Alex Deucher worked like a charm! 60FPS on TF2 and currently testing out L4D2 :D
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #22 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #21)
Second patch from Alex Deucher worked like a charm! 60FPS on TF2 and currently testing out L4D2 :D
Please attach your dmesg output.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #23 from Collin nothingmuchheretosay@gmail.com --- Created attachment 101268 --> https://bugs.freedesktop.org/attachment.cgi?id=101268&action=edit dmesg output
101191: testing patch fixes the DPM loop
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #24 from Arno Schuring aelschuring@hotmail.com --- Created attachment 101420 --> https://bugs.freedesktop.org/attachment.cgi?id=101420&action=edit dmesg with working bapm patch
I can confirm that the latter patch (attachment 101191) solves the issue for me, I haven't tried the earlier patch because it didn't work for Collin. I can re-test that if that's still useful.
Attaching dmesg; I compared the probed power states and they appear similar. What's bapm?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #25 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #24)
Created attachment 101420 [details] dmesg with working bapm patch
I can confirm that the latter patch (attachment 101191 [details] [review]) solves the issue for me, I haven't tried the earlier patch because it didn't work for Collin. I can re-test that if that's still useful.
Probably not necessary.
Attaching dmesg; I compared the probed power states and they appear similar. What's bapm?
It allows the CPU and GPU to share TDP headroom. E.g., if the CPU isn't busy, the the GPU can user higher performance states longer and vice versa.
On 6/20/2014 4:30 PM, bugzilla-daemon@freedesktop.org wrote:
*Comment # 25 https://bugs.freedesktop.org/show_bug.cgi?id=72921#c25 on bug 72921 https://bugs.freedesktop.org/show_bug.cgi?id=72921 from Alex Deucher mailto:agd5f@yahoo.com * (In reply tocomment #24 <show_bug.cgi?id=72921#c24>)
Createdattachment 101420 <attachment.cgi?id=101420> [details] <attachment.cgi?id=101420&action=edit> dmesg with working bapm patch
I can confirm that the latter patch (attachment 101191 <attachment.cgi?id=101191> [details] <attachment.cgi?id=101191&action=edit> [review] <page.cgi?id=splinter.html&bug=72921&attachment=101191> [review]) solves the issue for me, I haven't tried the earlier patch because it didn't work for Collin. I can re-test that if that's still useful.
Probably not necessary.
Attaching dmesg; I compared the probed power states and they appear similar. What's bapm?
It allows the CPU and GPU to share TDP headroom. E.g., if the CPU isn't busy, the the GPU can user higher performance states longer and vice versa.
And what happens if its disabled? Because as it stands now, the CPU and GPU are still throttled if heated up. The CPU's turbo core is disabled, is it the same for the GPU?
You are receiving this mail because:
- You are the assignee for the bug.
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 20, 2014 at 10:11 AM, Laszlo Kertesz laszlo.kertesz@gmail.com wrote:
On 6/20/2014 4:30 PM, bugzilla-daemon@freedesktop.org wrote:
Comment # 25 on bug 72921 from Alex Deucher
(In reply to comment #24)
Created attachment 101420 [details] dmesg with working bapm patch
I can confirm that the latter patch (attachment 101191 [details] [review] [review]) solves the issue for me, I haven't tried the earlier patch because it didn't work for Collin. I can re-test that if that's still useful.
Probably not necessary.
Attaching dmesg; I compared the probed power states and they appear similar. What's bapm?
It allows the CPU and GPU to share TDP headroom. E.g., if the CPU isn't busy, the the GPU can user higher performance states longer and vice versa.
And what happens if its disabled? Because as it stands now, the CPU and GPU are still throttled if heated up. The CPU's turbo core is disabled, is it the same for the GPU?
Right. They don't share the headroom if it is disabled.
Alex
You are receiving this mail because:
You are the assignee for the bug.
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=72921
Collin nothingmuchheretosay@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #26 from Collin nothingmuchheretosay@gmail.com --- Should this be marked as fixed or is there any other types of testing needed?
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #27 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #26)
Should this be marked as fixed or is there any other types of testing needed?
I need to push the patches upstream, but I'll be ding that this week.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #28 from Collin nothingmuchheretosay@gmail.com --- (In reply to comment #27)
(In reply to comment #26)
Should this be marked as fixed or is there any other types of testing needed?
I need to push the patches upstream, but I'll be ding that this week.
Was the patch pushed upstream yet? If so how would I know, because I'd like to upgrade to kernel 3.14 or 3.15 for better performance with my APU.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #29 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #28)
Was the patch pushed upstream yet? If so how would I know, because I'd like to upgrade to kernel 3.14 or 3.15 for better performance with my APU.
Not yet. It'll be in my -fixes pull request this week.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #30 from Kertesz Laszlo laszlo.kertesz@gmail.com --- I activated bapm on my A8-6500 (on a GA-F2A88X-D3H mobo). It is working as advertised - the CPU reached its 4GHz turbo core speed and was working between 3.5GHz(nominal top speed) and 4GHz for quite long time periods. Actually, from a performance point of view, this is the best so far (Catalyst had some nasty CPU slowdowns, not seen in /proc/cpu).
Now, the problems - about once a day the computer reboots suddenly. Every time my wife was playing some flash based Facebook game BTW. Using other stuff, even playing 3D games or using VDPAU acceleration didnt seem to create problems.
Also, i observed this in the system log:
[ 299.812285] mce: [Hardware Error]: Machine check events logged
/var/log/mcelog has these:
mcelog: failed to prefill DIMM database from DMI data mcelog: Unknown CPU type vendor 2 family 15 model 3 Hardware event. This is not a software error. MCE 0 CPU 0 BANK 4 ADDR feb0c114 TIME 1404369155 Thu Jul 3 09:32:35 2014 STATUS b600000000070f0f MCGSTATUS 0 MCGCAP 107 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 21 Model 3
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #31 from Kertesz Laszlo laszlo.kertesz@gmail.com --- I had some more reboots, some when the computer was idling. Now i reverted the patch and rebuilt the kernel, let's see if it will help.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
Rpnpif rpnpif@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rpnpif@free.fr
--- Comment #32 from Rpnpif rpnpif@free.fr --- This patch (bapm=true) fixed all bug issue that I had from 3.13 with MSI A78M-E35 motherboard with AMD APU A4-5300. My test are with 3.14.12 kernel and radeon.dpm=1.
More ! "vblank_mode=1 glxgears" give two times more fps than with radeon.dpm=0. Better temperature of the APU : cooler in idle mode and cool faster.
Succeed until now.
Thank you very much for your work.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #33 from Kertesz Laszlo laszlo.kertesz@infobenefic.ro --- So after more testing, i can confirm that activating bapm on my hardware (A8-6500 APU, Gigabyte GA-F2A88X-D3H mobo) leads to periodical sudden reboots (nothing in the logs).
Deactivating bapm makes the system stable again.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #34 from Collin nothingmuchheretosay@gmail.com --- (In reply to comment #33)
So after more testing, i can confirm that activating bapm on my hardware (A8-6500 APU, Gigabyte GA-F2A88X-D3H mobo) leads to periodical sudden reboots (nothing in the logs).
Deactivating bapm makes the system stable again.
That's another big problem, so there needs to be more testing for APUs with other hardware that's not MSI. Time to open up a new bug for that.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #35 from Matt mdinger.bugzilla@gmail.com --- Will this filter back to 3.15 or earlier? If so, how quickly? It'd be awesome if it filtered back before the ubuntu 14.04.2 release. This is on the Mint Linux release notes below which points to the ubuntu bug listed.
http://www.linuxmint.com/rel_qiana_xfce.php https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1309578
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #36 from Alex Deucher agd5f@yahoo.com --- I just sent a patch to the stable trees.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
Matt mdinger.bugzilla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mdinger.bugzilla@gmail.com
--- Comment #37 from Matt mdinger.bugzilla@gmail.com --- (In reply to comment #36)
I just sent a patch to the stable trees.
Awesome
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #38 from Matt mdinger.bugzilla@gmail.com --- Where do I look to check if the patch has landed yet? I have been scanning git repos and mailing lists since you stated that but am apparently looking in all the wrong places. Or does it just take longer than 2 weeks.
This is the only commit I can find anywhere that seems to be related but it's in 3.16: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/...
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #39 from Alex Deucher agd5f@yahoo.com --- You can check the stable branches here: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ Note that some stable trees are closed so they will not be getting any more updates.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #40 from Matt mdinger.bugzilla@gmail.com --- Okay. Thanks.
https://bugs.freedesktop.org/show_bug.cgi?id=72921
--- Comment #41 from FVerrac f0rhum@free.fr --- Just my 2 cents: I have this bug too, on a MSI A88XM-E35 desktop mobo with latest bios 30.3 and no OC settings. I posted my bisect at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1355044/ which drives to ... I will now have to understand what I read here and see what I can decide to workaround. Thank you for the job people here.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
bugzilla-daemon＠freedesktop.org -
Laszlo Kertesz