| 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.
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.
Created attachment 91047 [details] [review] testing patch Does the attached patch help? If so can you narrow down which options are causing the problem?
| What | Removed | Added |
|---|---|---|
| Product | Mesa | DRI |
| Version | git | unspecified |
| Component | Drivers/DRI/R600 | DRM/Radeon |
Created attachment 100359 [details]
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.
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
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.
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.
You might try a bios update if one is available for your board.
(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?
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).
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/+
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.
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).
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.
(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.
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?
(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?
(In reply to comment #17) > (In reply to comment #16) > > Created attachment 101179 [details] [review] [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.
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.
(In reply to comment #19) > Created attachment 101191 [details] [review] [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.
Second patch from Alex Deucher worked like a charm! 60FPS on TF2 and currently testing out L4D2 :D