Thanks alot for your help MikeyN, I'm pretty noobey at this, so feel free to describe stuff to me like I'm a 3 year old.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MBP 1,1-10,2 Force 2011 MacBook Pro 8,2 with failed AMD GPU to ALWAYS use Intel integrated GPU (EFI variable fix)
- Thread starter AppleMacFinder
- WikiPost WikiPost
- Start date
-
- Tags
- a1286 amd black screen blue and black screen discrete graphics dmg dmg files gfxcardstatus glitching gpu failure gpu panic gpu switch graphic card hardware fault hardware issue logic board failure macbook pro "15 2011 macbook pro (15-inch early 2011) macbook pro 2011 radeongate restart loop white screen
- Sort by reaction score
- Status
Thanks alot for your help MikeyN, I'm pretty noobey at this, so feel free to describe stuff to me like I'm a 3 year old.
a) an smc-reset should delete your mods.
b) unlikely. Sounds like you did an upgrade to Sierra over ElCap.
Try to make a USB-installer and make a clean install to another partition.
Only if your symptoms persist there you might consider more exotic explanation attempts.
Thank you for your fast reply, Mikey.
Do you mean I should leave the assumingly corrupt Siearra installation on the hd, but create a second partition and on that make a fresh install of Sierra?
Preferably onto an external disk.
But 2nd partition on the internal will also do, if you have the space.
Just make sure it's a clean install and you start your testing without letting loose the Migration Assistant.
Ok so, I downloaded gtxCardstatus and switched to integrated graphics, my MBP now works fine but seems to be slower than it was before, which is understandable/fine. still plays youtube videos, fine for checking email etc. but when I check ubnder arch linux it says I still have gpu-power-prefs still activated.....
It seems to work fine for now but will i have problems down the line... When I check about this mac under graphics it says Intel HD graphics 3000..so theoretically inst that the goal?
It seems to work fine for now but will i have problems down the line... When I check about this mac under graphics it says Intel HD graphics 3000..so theoretically inst that the goal?
Congrats. That is the goal.
It shouldn't be that much slower.
If not for graphics intensive stuff that would normally switch on the AMD I am hard pressed to really notice the difference here.
If you followed any of the guides here then what you describe is fully expected.
You first deleted it (e.g. through smc reset) then you set it – to a specific value. The latter is what you see under linux?
Possible problems down the line:
Check your temps! The GPU is likely to run much warmer than necessary now. Decide for yourself if having AMDRadeonX3000.kext loaded or not is desirable. That seems to help the most. Also try to run a fancontrol software that is more aggressive than Apple's preference.
Related is a possible reduction in battery-life, since the AMD in this state draws way too much power.
Unrelated, but still possible: the AMD chip might/will eventually fail completely. Then it's really game over.
Just wanted to let others know that I had the amd 6770m chip replaced over the weekend and got it back today.
The Macbook works perfectly with a clean install of Sierra and El Capitan.
I won't be using it to perform many, if any, gpu intensive tasks so, hopefully, it'll last a few more years.
Thanks to everyone for contributing to this great thread.
The Macbook works perfectly with a clean install of Sierra and El Capitan.
I won't be using it to perform many, if any, gpu intensive tasks so, hopefully, it'll last a few more years.
Thanks to everyone for contributing to this great thread.
Nice!
Could you share some more details?
How much did it cost?
Do you know the exact version of your new chip? (age, stepping, source)
Have they barked or balked at whether you were already in Apple's replacement program? (Only halfway trustworthy local shop here refused to do anything to boards already replaced by Apple. )
What do plan in the future in regard to Apple?
Still up for a class-action law suit?
Buying more of this gadget-level stuff at premium prices?
[I don't think they will change for the better if we do not act up much more.]
Could you share some more details?
How much did it cost?
Do you know the exact version of your new chip? (age, stepping, source)
Have they barked or balked at whether you were already in Apple's replacement program? (Only halfway trustworthy local shop here refused to do anything to boards already replaced by Apple. )
What do plan in the future in regard to Apple?
Still up for a class-action law suit?
Buying more of this gadget-level stuff at premium prices?
[I don't think they will change for the better if we do not act up much more.]
Here is the history of the mint condition late 2011 i7 15" MBP I had repaired:
It was purchased off the Kijiji Toronto buy/sell website two weeks ago for $65 CAD with 8 gb of ram (2 x 4 gb), charger, but no hard drive. I originally purchased this for parts as I needed an 85w magsafe charger, ram, and some bottom case screws and $65 was a bargain. When I picked it up, the seller told me that it does turn on but freezes or yields a white screen during the boot up process. Before the freezing issue, everything worked perfectly on the Macbook.
I took it home, tried to install Sierra and El Capitan without luck. Even changing the ram and different SSDs made no difference. I came to this thread to try and get it working so I could at least make sure everything worked before investing more time and money.
I took the buyer's word that everything worked and had the gpu replaced for $500 CAD. It may seem like a lot but these machines go for $700 in this condition and it's unknown how long the gpu in those machines will last.
Here's the TL,DR summary:
Original 2011 gpu replaced with a 2017 gpu for $500 CAD by Hamad of http://www.macrepaircanada.com/. Don't know how to determine stepping, etc.
He never asked or said anything about the Apple repair program.
I still have an early 2011 13" and late 2013 13" that I use. This 2011 i7 15" will be given to my brother.
Not sure that I could participate in a suit since I am not the original buyer.
It was purchased off the Kijiji Toronto buy/sell website two weeks ago for $65 CAD with 8 gb of ram (2 x 4 gb), charger, but no hard drive. I originally purchased this for parts as I needed an 85w magsafe charger, ram, and some bottom case screws and $65 was a bargain. When I picked it up, the seller told me that it does turn on but freezes or yields a white screen during the boot up process. Before the freezing issue, everything worked perfectly on the Macbook.
I took it home, tried to install Sierra and El Capitan without luck. Even changing the ram and different SSDs made no difference. I came to this thread to try and get it working so I could at least make sure everything worked before investing more time and money.
I took the buyer's word that everything worked and had the gpu replaced for $500 CAD. It may seem like a lot but these machines go for $700 in this condition and it's unknown how long the gpu in those machines will last.
Here's the TL,DR summary:
Original 2011 gpu replaced with a 2017 gpu for $500 CAD by Hamad of http://www.macrepaircanada.com/. Don't know how to determine stepping, etc.
He never asked or said anything about the Apple repair program.
I still have an early 2011 13" and late 2013 13" that I use. This 2011 i7 15" will be given to my brother.
Not sure that I could participate in a suit since I am not the original buyer.
Last edited:
ok so guys...I ****ed up.
while trying to install sierra on my hackintosh, i decided it would be a good idea to update my just newly working MBP to sierra to be able to access the new disk utility to format my bootable usb. mistakes were made.
now my MBP doesnt boot at all and just gets frozen when i'm at the login screen. do you think redoing these steps will fix these problems. also i dont evebn know if sierra is even fully installed.
while trying to install sierra on my hackintosh, i decided it would be a good idea to update my just newly working MBP to sierra to be able to access the new disk utility to format my bootable usb. mistakes were made.
now my MBP doesnt boot at all and just gets frozen when i'm at the login screen. do you think redoing these steps will fix these problems. also i dont evebn know if sierra is even fully installed.
After trying everything, i decided to track what happens to the efivars. Seems like the gpu-power-prefs... works normally after the workaround but gets deleted after rebooting from OSx. Seems Apple patched the new sierra release to not being able to disable csrutil function so my guess is that the SIP is deleting the custom made gpu-power-prefs-... file on normal reboot eventhough it has chattr +i. Dont know if it is intentional though. Also, you can only get sierra and lion through recovery, where you cannot instal lion for some reason... so you go with patched sierra and the problem persists. I will try finding another way to install OSx other than sierra and see what is going on.
PS MBP worked correctly with only the EFI fix. Did not delete the kexts.
PS MBP worked correctly with only the EFI fix. Did not delete the kexts.
Would installing Sierra using another Mac and putting the freshly installed Sierra hard drive into the non-booting Macbook help? I'm just guessing here.
## Newer DiskUtility versions are a downgrade compared to older versions.
boot verbose mode (cmd-v after pressing power, or sudo nvram boot-args="-v")
If you see a message that's mentioned in this thread…
My guess here is that a newly installed system has AMDRadeonX3000.kext in /System/Library/Extensions active and that's not playing nice with the gpu-power-prefs.
If that is the case:
boot from another drive and move the kext out of there; do not immediately reboot –wait for the kextcache process finishing its work
Or; external drive unavailable: follow this guide for Sierra: #429. (Trace all the steps, but step 5 is the magic.)
I was able to solve my problem regarding fans going wild and kernel_task going crazy and would like to post my solution in case anyone experiences the same problem.
The culprit was the faulty thermal sensor of the GPU which made kernel_task throttle the whole system in order to prevent damage through potential overheating. And the solution in short is to remove a kernel extension from IOPlatformPluginFamily.kext.
See http://blog.viktorpetersson.com/post/136535061619/how-to-fix-kerneltask-cpu-usage-on-el-capitan for a full how-to.
Since that kernel_task CPU usage has gone back to normal and I was able to apply the initial fix posted by AppleMacFinder.
I'd like to thank MikeyN and all the other helpful people here for their work.
The culprit was the faulty thermal sensor of the GPU which made kernel_task throttle the whole system in order to prevent damage through potential overheating. And the solution in short is to remove a kernel extension from IOPlatformPluginFamily.kext.
See http://blog.viktorpetersson.com/post/136535061619/how-to-fix-kerneltask-cpu-usage-on-el-capitan for a full how-to.
Since that kernel_task CPU usage has gone back to normal and I was able to apply the initial fix posted by AppleMacFinder.
I'd like to thank MikeyN and all the other helpful people here for their work.
Glad you got it sorted. My next project is to have the c9560 capacitor replaced on my brother's mid-2010 15" Mbp that was also the subject of an Apple repair program.
I also do not trust the actual readings of said sad sensor. At least not anymore now.
But is removing the entire plist really a casual solution without side effects?
How are the other temps now? The exterior of the case?
That miserable son of chip really does still get warm.
The plist is indeed an interesting file to examine. Thanks for that.
Hello to everyone and thanks for the great job done!!!!
Reading this thread several hours and almost every 10 minutes finding new information.
I`m already confused with:
Reading this thread several hours and almost every 10 minutes finding new information.
I`m already confused with:
- AMDRadeonX3000.kext versions
- sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
vs
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
- how to load AMDRadeonX3000.kext automatically after login (autorun)? Is it possible at all?
Last edited:
So what happens to my MBP is that after a normal reboot, even without kexts, my dgpu is up again and the gpu-power-prefs-... has defaulted. The proccess is being fulfilled at the shutdown/rebooting of the system. A workaround, not comfortable though, was to open terminal before rebooting/shutdown and type in:
sudo nvram gpu-power-prefs=%01%00%00%00
sudo reboot
That would reboot the system and schedule nvram to be chosing igpu in next boot. Worked every time i tested. I tried to implement the first line on every startup with a shell command but it did not work as the shutdown has to be done immediately after the nvram mod from withing the terminal. Tried to make custom restart/shutdown shell executables through terminal with double click, but weird enough, it only worked some of the times.
Fact is that making gpu-power-prefs-... immutable in archlinux with chattr +i does not render the file immutable in macos for some reason.
Guessing: The fa28e....-6815686e30f9 is making me suspect that it is a physical identifier to the AMD gpu device. There is another identifier (something with many 7s) that might be the intel's gpu device identifier (class guid).
(Suspecting that for that windows device class Guid and Bus type Guid are extremely similar, even at the level of how many digits per digit group they have!)
I write that cuz after the third successful reboot, i went in archlinux again to see the structure of files in efivars with ls. What i discovered was that the gpu-active-... was the intel's identifier and the gpu-power-prefs-... and the gpu-policy-... had been also turned to that of the intel's identifier.
After that I explored the printf file with nano. ' Printf "content" > something ' is a linux command to write the "content" in the file named something, in our case \x07\x00\x00\x00\x01\x00\x00\x00. Within the file, all i could see was ^G^@^@^@^A^@^@^@. I guess ^G is the \x07, the ^A is the \x01 and the ^@ is the \x00. While the other 2 gpu-... related filed had nothing at all.
Though I am not as experienced in programming, maybe there is someone that can explore that finding or know someone that would search into it.
sudo nvram gpu-power-prefs=%01%00%00%00
sudo reboot
That would reboot the system and schedule nvram to be chosing igpu in next boot. Worked every time i tested. I tried to implement the first line on every startup with a shell command but it did not work as the shutdown has to be done immediately after the nvram mod from withing the terminal. Tried to make custom restart/shutdown shell executables through terminal with double click, but weird enough, it only worked some of the times.
Fact is that making gpu-power-prefs-... immutable in archlinux with chattr +i does not render the file immutable in macos for some reason.
Guessing: The fa28e....-6815686e30f9 is making me suspect that it is a physical identifier to the AMD gpu device. There is another identifier (something with many 7s) that might be the intel's gpu device identifier (class guid).
(Suspecting that for that windows device class Guid and Bus type Guid are extremely similar, even at the level of how many digits per digit group they have!)
I write that cuz after the third successful reboot, i went in archlinux again to see the structure of files in efivars with ls. What i discovered was that the gpu-active-... was the intel's identifier and the gpu-power-prefs-... and the gpu-policy-... had been also turned to that of the intel's identifier.
After that I explored the printf file with nano. ' Printf "content" > something ' is a linux command to write the "content" in the file named something, in our case \x07\x00\x00\x00\x01\x00\x00\x00. Within the file, all i could see was ^G^@^@^@^A^@^@^@. I guess ^G is the \x07, the ^A is the \x01 and the ^@ is the \x00. While the other 2 gpu-... related filed had nothing at all.
Though I am not as experienced in programming, maybe there is someone that can explore that finding or know someone that would search into it.
Last edited:
That's a strange finding.
sudo nvram gpu-power-prefs=%01%00%00%00 is incomplete and I guess just an abbreviation for:
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
If you do not have other hacks active (gpu-swich, gfxCardStatus, other login/log-out hooks come to mind) then it would be interesting to know if the described behavior persists after completely clearing efivars (smc-reset & nvram-reset) and then setting the primary hack of this thread again.
It is incomplete but it works just like that after a successful boot. And no, i have no other hooks. But, if you clean nvram, the pc will bootloop due to rebuilding the gpu-... related files and activating the dGPU and not being able to boot to it. I edited my post with more info if you would like to re read it.
[doublepost=1501771268][/doublepost]Theorycrafting more into it, and assuming there is a logical structure into it, setting the gpu-power-prefs to (=) %07%00%00%00 instead of %01%00%00%00 would result into the dGPU being the primary boot gpu. But the main problem persists; MacOs overwrite that file on every reboot when not being specificly instructed to what to do.
My reasoning was that the nvram might have conflicting settings that are 'sanitized' to revert to dGPU.
After resetting smc and pram (so they are clear and minimal defaults again) you should still be able to boot into single user (although with presumably funky graphics) and set the (complete) variable.
Fact is that the MBP always starts off fine. Single user or recovery also fine. Only when drivers need to be loaded it fails and hangs up. Another fact is that if the dgpu fails during the apple logo loading, the screen will turn off and then the WSOD will appear and it will reboot after a while and go on like that. If it fails within MacOs, it will just freeze the MBP. So i suspect that the best way to overcome this, is by preventing it to load the dgpu. Though they way mbp works is that in order to disable the dgpu it has to enable it first....... and that must be cuz they are in the same pcie lane prior to the monitor.
[doublepost=1501771988][/doublepost](Easter eggs: I had a BSOD twice as well hahahaha)
Assuming "latest macOS" means 10.12.6.
AMDRadeonX3000.kext versions seem to be irrelevant to success. It currently looks that they should be at their default versions for the respective systems. Some people even report that they could leave it at the default location.
Having them loaded (after boot) strips me on Yosemite from having sleep and hibernate working correctly. Also Yosemite is now quite slow to shutdown. Both features work for me in Sierra and HighSierra as they should.
The system will likely work completely without the kext, albeit quite likely with higher temperatures on the now useless dGPU.
Autoloading the kext is a problem that I do not have a solution for, and since I am still on Yosi for main work this is a goodthing™.
May be shellscript with the privileges set accordingly should do the trick. A launchd solution; haven't yet tested this, may contain errors:
Assuming that the kext was moved to /System/Library/Extensions-off
enter the following in Terminal:
$ sudo nano /Library/LaunchDaemons/com.lateX3000.plist
copy the following code into the file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.lateX3000.plist</string>
<key>ProgramArguments</key>
<array>
<string>kextload</string>
<string>/System/Library/Extensions-off/AMDRadeonX3000.kext</string>
</array>
<key>RunAtLoad</key><true/>
</dict>
</plist>
Now make it 'active':
$ sudo chown root:wheel /Library/LaunchDaemons/com.lateX3000.plist
$ sudo chmod 644 /Library/LaunchDaemons/com.lateX3000.plist
$ sudo launchctl load -w /Library/LaunchDaemons/com.lateX3000.plist
[
Update:
Naturally the plist contained a typo. Now I tested it. It works. But it is in its current form invoked too early. If someone knows how to postpone the execution?
Update 2:
$ sudo mkdir -p /Library/LoginHook
$ sudo nano /Library/LoginHook/LoadX3000.sh
contents:
#!/bin/bash
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
exit 0
$ sudo chmod a+x /Library/LoginHook/LoadX3000.sh
$ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh
Method in Update2 works reliable: kext is autoloaded late enough.
Please feel free to improve on this script.
e.g. Add a line to test whether kext is already loaded?
]
The effect of the two methods – efivars vs nvram – should be the same.
nvram is way faster to accomplish and possible with onboard equipment. The efivars way may still be useful under linux, for linux and for exploring the other efivars settings.
If you are on OS X, go nvram.
Last edited:
I second that motion! It is difficult to parse out what needs to be done with so much going on in this thread.
I would really like to see a clean "up to date" information in a single post.