Created
April 30, 2018 22:56
-
-
Save 3on/6c0be14eac8a9c5ec606f85ee20a2eae to your computer and use it in GitHub Desktop.
MBP late 2011 AMD GPU disabling
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Links | |
* https://apple.stackexchange.com/questions/267581/gpu-problem-boot-hangs-on-grey-screen/295805#295805 | |
* https://forums.macrumors.com/threads/force-2011-macbook-pro-8-2-with-failed-amd-gpu-to-always-use-intel-integrated-gpu-efi-variable-fix.2037591/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The initial procedure: | |
Part 1: Disable SIP, disable dGPU, move one kernel extension | |
To start from a clean slate: reset SMC and NVRAM: | |
shutdown, unplug everything except power, now hold | |
leftShift+Ctrl+Opt+Power | |
and release all at the same time; | |
Now power on again and hold | |
Cmd+Opt+p+r | |
at the same time until you hear the startup chime two times. | |
Boot into Single User Recovery by holding | |
Cmd+r+s | |
Disable SIP: enter: | |
csrutil disable | |
disable dGPU on boot with setting the following variable: | |
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 | |
enable verbose boot mode: | |
nvram boot-args="-v" | |
reboot into Single User-mode by holding | |
Cmd+s | |
on boot | |
mount root partition writeable | |
/sbin/mount -uw / | |
make a kext-backup directory | |
mkdir -p /System/Library/Extensions-off | |
only move ONE offending kext out of the way: | |
mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/ | |
inform the system to update its kextcache: | |
touch /System/Library/Extensions/ | |
reboot normally: | |
You should now have an iGPU accelerated display, but the system doesn't know how to power-management the failed AMD-chip. (In this state the GPU is always idling with relatively high power, consuming quite a bit of battery when unplugged and leading to GPU temperatures from 60°C upwards [on average 60-85°C], despite not being used for anything by system.) | |
Part 2: improve thermal and power management | |
For improved power management of the disabled GPU you have to either manually load the one crucial kext after boot by: | |
sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext | |
If you have a temperature sensor application you might want to have it open before issuing the above command and watch the temps drop… | |
Automate this with the following LoginHook that will get executed after the next reboot: | |
sudo mkdir -p /Library/LoginHook | |
sudo nano /Library/LoginHook/LoadX3000.sh | |
with the following content: | |
#!/bin/bash | |
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext | |
pmset -a force gpuswitch 0 # undocumented/experimental | |
exit 0 | |
then make it*1 executable and active: | |
sudo chmod a+x /Library/LoginHook/LoadX3000.sh | |
sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh | |
*1: The undocumented use of this pmset command seems to improve sleep/wake/shutdown behaviour. If it doesn't, experiment with leaving it out. | |
See the Disclaimer below. The following is just speculation: sleep/wake/shutdown may remain troublesome. The theory here is that "something slowly corrupts" what is saved in the SMC. Therefore, resetting the SMC and re-applying the variable hack seems to alleviate the situation for a time. (Permanent solutions for this welcome!) As short time workarounds you might want to try to avoid "lid-closing sleep", that seems to give more trouble than other methods (Apple-Menu, Keyboard-Shorcut). Apparent hangs on shutdown are usually just very long delays that will shutdown, eventually, cleanly and successfully. | |
Unscientific sampling suggests that Yosemite is worst for this and El Capitan and Sierra much better behaved in this regard. | |
Manually or otherwise delayed loading of this crucial kernel extension allows the system to handle power management a bit better. The battery will be less used and the temperatures emanating from the unused GPU will drop to a range significantly below 50°C (on average between 15-50°C). | |
For proper power management the minimal set of loaded kexts are on boot (versions for 10.12.6, check with kextstat | grep AMD): | |
com.apple.kext.AMDLegacySupport (1.5.1) | |
com.apple.kext.AMD6000Controller (1.5.1) | |
com.apple.kext.AMDSupport (1.5.1) | |
com.apple.kext.AMDLegacyFramebuffer (1.5.1) | |
And if the above method of loading succeeded this should appear added to the list: | |
com.apple.AMDRadeonX3000 (1.5.1) | |
A final step is to reboot once again into SingleUserRecovery | |
Do this with Cmd+r+s | |
after the commandline becomes active, enter: | |
nvram boot-args="-v agc=0" | |
and reboot normally. | |
This will cool down the dGPU a bit further. | |
It is imperative to issue this command from SingleUserRecovery since the system with SIP enabled will block your attempts to set this variable when booted from the normal boot volume, whether in normal full boot mode or regular SingleUser. It is important to note that therefor this step cannot be easily integrated into the force-iGPU.sh script (that you will be creating in a minute) and has to be repeated on its own after a NVRAM reset. | |
This last step assumes that SystemIntegretyProtection has been reenabled. But if SIP is intentionally and permanently kept off, then this step can be integrated in the force-iGPU.sh script above. | |
But since somehow I intended to keep SIP off permanently and it was turned back on without me noticing it, reliance on SIP staying "off" might be not the best approach. Clearing NVRAM, where SIP settings are stored, might be one such unforeseen disturbance. | |
Preventive measures for future use | |
There are two further caveats to know: This is reversible when the SMC/NVRAM is reset. If that happens the GPU-power-pref NVRAM-variable can or even has to be set again to force the use of the iGPU from boot-time. | |
Since this can happen quite easily (and is often erroneously recommended way too many times than it is actually useful), you should probably prepare for such a scenario and create a simple script to greatly speed up the process and also make entering the necessary variable much less error prone: | |
sudo nano /force-iGPU-boot.sh | |
– Enter the following content to this file: | |
#/bin/sh | |
sudo nvram boot-args="-v" | |
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 | |
exit 0 | |
– Now make that executable: | |
sudo chmod a+x /force-iGPU-boot.sh | |
In the future, when the SMC/PRAM/NVRAM gets reset to default values it is now possible to boot into SingleUser with: | |
Cmd+s | |
– And after mounting your boot-volume read-write to execute just this single line: | |
sh /force-iGPU-boot.sh | |
Remember that the agc variable is now also cleared. (See above) | |
Part 3: Handling Updates from Apple | |
This setup has now one kext in a place Apple's installers do not expect. That is why in this guide SIP has not been reenabled. If an update that contains changes to the AMD drivers is about to take place it is advisable to move back the AMDRadeonX3000.kext to its default location before the update process. Otherwise the updater writes at least another kext of a different version to its default location or at worst you end up with an undefined state of partially non-matching drivers. | |
After any system update the folder /System/Library/Extensions has to be checked for the offending kext. Its presence there will lead to e.g. a boot hang on Yosemite and Sierra, an overheating boot-loop in High Sierra. | |
Upgrading to High Sierra 10.13: with this hack in place is almost straightforward: Despite applying a firmware update the installation process should not touch the NVRAM variable. The installation process also does not use a fully accelerated AMD chip but basic acceleration that is not problematic regarding this hack. However, as noted in the paragraph above the first boot into a system that is finished installing but just about to start the setup process will produce a heat/crash induced boot loop. The offending kernel extension has to be moved again like described above. (Starting at Step 3) After moving the kext, all shall be well. | |
Closing Remarks and Recommendations | |
Further: this laptop is overheating, no matter what you do. The cooling system is inadequate and the huge number of failing AMD chips are just proof of that. | |
To prolong the life of this now hacked machine it is advisable to abstain from really heavy lifting over prolonged stretches of time. Strictly follow the usual recommendations for laptops: use on hard surfaces, keep the fans and fins inside it clean. Using any fancontrol software with relatively aggressive settings should also help: like smcFanControl, MacsFanControl, or TGPro (both commercial). | |
Disclaimer: This whole procedure is no magic bullet. The state of failure for these chips not 100% predictable. Very few users have issues even with this hack in place: there might be issues with rebooting, going to sleep or waking up properly, most of them coming from users with Yosemite, the least trouble seems to be on Sierra. In these cases it seems sometimes necessary to not use the AMDRadeonX3000.kext, and therefore also not the LoginHook from Part 3. (But see the additional note under *1 above.) A disproportionate number of users on High Sierra report issues with their displays backlight adjustment. So currently, the sweet spot for choice of operating system is in my view 10.12 Sierra. | |
In some cases, even with all these measures in place it seems that the still functioning Thunderbolt port will cause some issues if any peripherals are attached and active when the machine goes to sleep. After this happens any subsequent sleep cycle might be affected and an NVRAM reset with subsequent variable setting dance outlined above will be necessary, again. It seems advisable in such cases to either prevent machine sleep or unplug any hardware on the Thunderbolt port before letting the machine sleep. | |
Within the restrictions outlined at the start of this answer: Most users report complete success. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment