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
@Panavision241, no, this is to confirm the EFI GUID used in the nvram set command applies to Snow Leopard also (and probably other OS X versions).
Hello first of all thank you for this amazing fix. My macbook pro late 2011 gpu died and i was stack at grey screen and i was not able to boot to recovery to reinstall mac os. After i followed the guide i was able to boot fo recovery and reinstall the OS but somewhere in the installation progress the mac while booting stack on logo loading bar. I dont know what to do please help .
I just signed in to give a big thumbs up to @AppleMacFinder and @totoe_84 (and all the other who have contributed to this thread) and a warm THANK YOU for this amazing solution! My MacBook Pro is no longer eating the dust of my drawer now! 
The only tip I can give about the fix (if not already shared in the many previous messages) is that relocating the drivers is somehow mandatory for the fix to work through multiple boots/restarts. For that purpose, I just followed the instructions and code lines to be entered in Recovery Mode right after the reboot from Arch Linux and that did it for me!
Again, many many thanks to you all!
Cheers from my early 2011, (now disabled) AMD HD6750M-equipped 15'' MBP
The only tip I can give about the fix (if not already shared in the many previous messages) is that relocating the drivers is somehow mandatory for the fix to work through multiple boots/restarts. For that purpose, I just followed the instructions and code lines to be entered in Recovery Mode right after the reboot from Arch Linux and that did it for me!
Again, many many thanks to you all!
Cheers from my early 2011, (now disabled) AMD HD6750M-equipped 15'' MBP
The key to surviving a reboot is changing a file in the EFI partition. See nsgr's post #613.
I think the last step by step guide in this thread was posted by SirMeowington5 post #528. That is the process I follow when updating macOS...
Last edited:
Were you able to resolve the issue?
Booting into recovery mode is done to move a certain file (kernel extension) out of a specific system folder in order to disable the use of the discrete graphics chip. Instead of reinstalling the OS, go to the Utilities menu and launch Terminal. In the terminal window, run the three commands as listed in post #528. And then continue with a normal reboot, followed by loading the kernel extension from Terminal again.
Hoorey! Finally I managed TheFix to survive against reboots.
The solution is https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-22#post-24835359
The key is kext moving.
Now, main problem to me is to make sudo kextload AMDRadeonX3000.kext command execute automatically after system boot.
The solution is https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-22#post-24835359
The key is kext moving.
Now, main problem to me is to make sudo kextload AMDRadeonX3000.kext command execute automatically after system boot.
[doublepost=1502569054][/doublepost]I got a problem with removing the gpu-power-prefs can u help me it says not prommit can not be removedIf you don't have time to read my story (which also describes some interesting technical approaches) just scroll down this thread until a "100% WORKING SOLUTION" text
Discrete AMD GPU of my 2011 MacBook Pro 8,2 has finally failed because of the reasons mentioned here ( http://logicboardmac.blogspot.ru/ ) and there ( https://www.macrumors.com/2015/02/19/2011-macbook-pro-repair-program-apple/ ) . It has been working perfectly for 6 years under quite a high load, even tried SETI@HOME mining at background! So I was confident that my MBP is not affected by bad solder / bad soldering quality and didn't want to bring it to Apple for a free repair program - partially because couldn't find the time to pause my important software projects, partially because I was afraid that Apple might give me a less reliable logic board or refuse a free repair because of the several unrelated repairs that I did manually by myself earlier to save money: changed thermal paste a few times, replaced the internal battery 2 times, replaced a keyboard with broken buttons, etc. But it finally broke down last week: laptop's screen image became distorted, it refused to boot OS X (always freezing half-way), and - Apple free repair program has already ended! I know there are affordable solutions like $50 BGA resoldering at unofficial local repair shop and that its possible to get a new replacement HD 6750M chip from AliExpress for $35 or cheaper ( http://www.aliexpress.com/item/DC-2...0028-216-0810028-BGA-Chipset/32764872143.html or https://www.aliexpress.com/item/DC-2015-New-216-0810001-216-0810001-Graphic-Chipset/32718112928.html , because don't know if this is true - https://www.rossmanngroup.com/board...0604-replace-216-0810005-gpu-with-216-0810028 ) to guarantee a successful repair, so the total price of repair would be either $50 or $50+$35=$85 - less than $100 in any case. But I don't like investing money to the old computers, so I have thought - what if there is some hack to force MBP to use integrated graphics ALL THE TIME, even while booting ? And then started to explore the possible solutions...
===
First of all, it is possible to successfully boot a MBP to OS X while still using the failed GPU, after you remove the AMD drivers by booting in command line mode (CMD+S) and entering these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot
The degree of your inconvenience while doing these steps - strongly depends on how heavily a screen's image is distorted in your case. In my case it was even more difficult because the OS X partition became a "read-only" partition (because of too many emergency shutdowns I did while desperately trying to boot OS X with a failed GPU) so I had to remove a hard drive from MacBook Pro and (using a USB to SATA 2.5" adapter taken from my portable HDD) attached it to a computer with Linux, then followed these instructions:
https://superuser.com/questions/961401/mounting-hfs-partition-on-arch-linux (1st answer) - carefully executed a number of commands, calculated a sizelimit for my parition layout, and finally ran sudo mount -t hfsplus -o force,rw,sizelimit=YOURNUMBER /dev/sdb2 /mnt to mount this HFS+ partition to /mnt directory in read-write mode. Then I performed these "1)-7)" steps you see above, and also repaired a filesystem by running sudo fsck.hfsplus -f /dev/sdb2 before unmounting a partition with sudo umount /mnt and putting a hard drive back to MBP...
===
This gave me a MBP which could boot to OS X although STILL using a broken AMD GPU: so it screen's image is very distorted (could browse the Internet but quite inconvenient to read a text), Launchpad is super laggy, and you can't switch to Integrated GPU using gfxCardStatus because: without AMD drivers (which we had to remove to successfully boot to OS X) Macbook Pro thinks its' internal screen is External Display and gfxCardStatus tells it is impossible to switch because External Display is using AMD GPU. Somewhere I found a suggestion that it is possible to rebuild a gfxCardStatus from the source code - https://github.com/codykrieger/gfxCardStatus - with removed or commented out 156-166 lines in the ./gfxCardStatus/Classes/GSProcess.m to make it to ignore the external display:
// find out if an external monitor is forcing the discrete gpu on
CGDirectDisplayID displays[8];
CGDisplayCount displayCount = 0;
if (CGGetOnlineDisplayList(8, displays, &displayCount) == noErr) {
for (int i = 0; i < displayCount; i++) {
if ( ! CGDisplayIsBuiltin(displays))
[list addObject:[NSDictionary dictionaryWithObjectsAndKeys:
Str(@"External Display"), kTaskItemName,
@"", kTaskItemPID, nil]];
}
}
So I rebuilt a gfxCardStatus using the instructions from the last reply of this issue -
https://github.com/codykrieger/gfxCardStatus/issues/229
(also had to download a MacOSX10.11.sdk from here - https://github.com/phracker/MacOSX-SDKs/releases - unpack and copy it to XCode's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk - because of the Apple's stupidity the latest XCode for El Capitan does not include SDK for El Capitan!) However, it still didn't work - gfxCardStatus only pretended that it has switched to Integrated GPU, while in reality OS X did not let it switch! Even after I edited ./gfxCardStatus/Classes/GSGPU.m file to enable the mysterious "Nuke it from orbit switching" option, it still couldn't switch...
===
Then I discovered this interesting repository - https://github.com/0xbb/gpu-switch - which is partially similar by its' source code to gfxCardStatus but also has the "Login Hooks" (install_hooks.sh) to "automate the switching process for login/logout". Sadly it didn't work for me... However, there is a very interesting gpu-switch text file right at the root of this repository, which describes the EFI variables!
https://github.com/0xbb/gpu-switch/blob/master/gpu-switch
After studying it and also reading this issue's comments - https://github.com/0xbb/gpu-switch/issues/11 - I became confident to try this solution, but found out that my MacBook Pro 2011 8,2 with OS X El Capitan 10.11.6 is in a VERY problematic situation:
1) rEFInd is not installed, and to install it - must disable SIP protection. But I cannot boot to Recovery mode (Command+Option+R) or to OS X Installation DVD/USB (hold Option), (to disable SIP), because they freeze while booting! - although I removed AMD kexts from my system, of course these recovery tools are using AMD kexts integrated to their design. Also cannot use Rootfool hack ( https://github.com/gdbinit/rootfool ) to disable SIP during runtime, because it works only at OS X version older than 10.11.4
2) Tried overheating my Macbook Pro on purpose (forcing CPU usage to 100% and putting it to a tightly closed bag) to force it to shutdown from overheating and then quickly reboot so that Integrated graphics will be enabled during the boot time - making it possible to boot to Recovery. But because of the wonderful high end thermal paste I have applied not so long ago - cannot overheat it even after waiting for a long time! At this point I thought that could either: a) remove AMD kexts from Installation media, or b) to connect MBP's hard drive to a Linux machine again and run a bunch of chmods to remove the SIP flags from the directories mentioned here ( http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really ) which could potentially make a system unbootable, or c) to try installing rEFInd to HFS+ partition directly from a Linux machine with root rights because it will bypass SIP --- but have not explored these options, although some of them might have worked...
3) Wanted to boot a Linux LiveCD to edit the EFI variables from there, but no matter what I did: tried booting straight without GRUB option modifications, tried editing GRUB boot options (with "e" key) to add nomodeset / remove quiet splash / or both in every combination , or like suggested in this article ( https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011) ) also add i915.modeset=0 radeon.modeset=0 or radeon.modeset=0 i915.modeset=1 i915.lvds_channel_mode=2 ; and then pressed Fn+F10 or Shift+Ctrl+Fn+F10 to boot with these options: but the Linux boot process always failed at different boot stages, no matter what popular user-friendly Linux distribution or what version of it I am trying: tried many releases of Ubuntu / Lubuntu / Fedora , even the old "AMD64 Mac" and "Alternate AMD64 Mac" images, but they always failed - either at the very beginning of boot process (black screen, or a black screen with a blinking or stuck _ character at the left upper corner) or failed at the very end of it - right before it is supposed to show a graphical desktop environment...
Later, totoe_84 wrote that he was able to boot Ubuntu in graphical mode using the following setup for GRUB:
- To disable the AMD graphics card I added the following lines after set gfxpayload=keep
outb 0x728 1
outb 0x710 2
outb 0x740 2
outb 0x750 0(based on https://ubuntuforums.org/showthread.php?t=2157775 )
- Next I added the following after quiet splash
i915.lvds_channel_mode=2 i915.modeset=1 i915.lvds_use_ssc=0
===
Then I remembered that there are not-mainstream Linux distributions for advanced users, which have a LiveCD without any graphical interface: you are dropped to a pure console and you are supposed to install the system along with only those graphical interfaces and software packages / groups of packages which you explicitly select. For example: Arch Linux (https://www.archlinux.org/) and Gentoo Linux (https://gentoo.org/) . Because their LiveCD does not have a graphical interface, they could be booted without a problem to a pure Linux console and there you could edit the EFI variables ! So here is a...
===
=== 100% WORKING SOLUTION
===
=== Force your MBP to ALWAYS use Intel integrated GPU (EFI variable fix)
===
=== to make it great again !
===
1) Create the Arch Linux LiveCD/LiveUSB :
You need a working computer for that and a spare CD/DVD/USB drive. Download the latest Arch Linux ISO image from this page - https://www.archlinux.org/download/ , at the time of writing it is archlinux-2017.03.01-dual.iso . Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB: use the great detailed instructions from this page, https://wiki.archlinux.org/index.php/USB_flash_installation_media
2) Boot to it: insert this CD/DVD/USB to Macbook Pro, hold Option key while booting, choose "EFI boot" (that is your bootable installation media), press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter. If everything is done correctly, you will find yourself at the Linux console!
3) Edit EFI vars: looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a "gpu-power-prefs-..." variable (where ... is UUID of this variable). If there is such a variable, its better to remove it with rm. In my case the efivarfs has been mounted by default with read/write permissions, but if you are getting the "operation not permitted" message while attempting to rm, it means that in your case efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again (credits to totoe_84 for this valuable addition) :
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/
If your screen is so distorted that it is difficult to see the letters, just start typing the rm gpu-power-pre and then press TAB key for autocompletion. In my case there were not such a EFI variable, only "gpu-active-..." and maybe somehow related "gfx-saved-config-restore-status-..." . Then I looked again at that gpu-switch text file (mentioned above, https://github.com/0xbb/gpu-switch/blob/master/gpu-switch),
and entered THESE COMMANDS:
*) chattr -i "/sys/firmware/efi/efivars/" <----- skip this command
Actually a gpu-switch script had "${sysfs_efi_vars}/${efi_gpu}" but I didnt have a "gpu-power-prefs-..." variable - so, partially by mistake, I didn't add that efi_gpu suffix and entered this incomplete path accidentally
*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a gpu-switch script
*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"
http://www.tecmint.com/chattr-command-examples/ - chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
...
Syntax of chattr ---> chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (+i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...
Operator
This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances
- + : Adds the attribute to the existing attribute of the files.
- – : Removes the attribute to the existing attribute of the files.
- = : Keep the existing attributes that the files have.
*) cd /
Could not unmount efivars if you are inside this directory, so change to the root directory
*) umount /sys/firmware/efi/efivars/
Guarantees that your EFI variables are flushed to efivarfs filesystem, please unmount it safely before rebooting)
*) reboot
===> IF YOU DID EVERYTHING CORRECTLY, MOST LIKELY THAT YOUR MACBOOK PRO IS NOW USING INTEGRATED GRAPHICS WHILE BOOTING, AFTER BOOTING, AND IS WORKING GREAT AGAIN !
In the future maybe you could need to re-apply this solution if you would have to reset your PRAM / NVRAM / SMC because of some other problems, so remember this solution somewhere... Funny thing: now you can't switch to Discrete GPU even using gfxCardStatus, it is forever stuck at Integrated
I spent two working days to discover this solution, and really hope that it will work flawlessly for every MBP owner with a broken discrete GPU. Good luck!
Attachments
Boot verbose is mandatory for all Macbooks with this Died GPU problem. Avoid the Apple logo with progress bar.
Boot Single User (Command + S)
sudo nvram boot-args="-v"
reboot
You're probably having trouble with the AMDRadeonX3000.kext that was not moved from /System/Library/Extensions .
Boot the verbose and see if the last lines have the famous IOConsoleUsers IOScreenLockState 3. If you have this problem, then you did not move the AMDRadeonX3000.kext.
The installation of Mac OS takes place in two parts:
1 - Format the system partition and copy the installation files.
2 - Restart Macbook Pro and continue installation and Rebuild Cache
localhost com.apple.xpc.launchd[1] : Extension SDK cache is not present. Attempting to rebuild…
then freeze in IOConsoleUsers IOScreenLockState 3
See the post SirMeowington5 - Boot into recovery mode (Command + r)
https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-22#post-24835359
[doublepost=1502570046][/doublepost]
The gpu-power-prefs file is protected by immutability. You have to remove immutability with the chattr command.
Use the chattr -i command before the rm command.
1 - chattr -i gpu-power-prefs....
2 - rm gpu-power-prefs...
List attributes -> +i -> The file has immutability.
lsattr /sys/firmware/efi/efivars/
[doublepost=1502571756][/doublepost]
Do not modify the AGPM.
Are you having this error with an external gpu connected to Macbook Pro? Or is this error only with the Intel and Nvidia GPUs?
My starting point for the IOScreenLockState IOConsoleUsers was that after the sudo nvram GUID: gpu-power-prefs=%01%00%00%00, I realized that the Recovery Mode Graphical Interface worked correctly.
So I ran the ioreg command and saw the AMD kexts loaded.
For the Nvidia video card there must be something more because it has something with NVArch and also DeviceID.
Recovery Mode:
ioreg | grep -i nvdia
ioreg | grep -i nvda
ioreg | grep -i GK107M
ioreg | grep -i 0fe9
You have to compare the Recovery Mode kexts and the kexts of your Mac OS installed on the hard disk.
Recovery Mode -> OS Base System -> /System/Library/Extensions
Mac OS installed hard disk -> /System/Library/Extensions
Recovery mode has fewer Nvidia kexts. If the graphic interface works, then you have to focus on these kexts.
Normal boot:
grep -Ril nvda /System/Library/Extensions/
/System/Library/Extensions//AppleVADriver.bundle/Contents/MacOS/AVA_HD_VP3.dylib
Open the file AVA_HD_VP3.dylib with TextEdit and you will see several references to NVDA and Nvidia.
I do not know if this file might be the problem.
Dylib = dynamic library
Last edited:
My solution to that is don't reboot. Sleep. When I'm done I just close the lid. When I open, it wakes up, and takes me to where I left off. Safe Sleep mode saves the contents of ram to HD, and shuts down. It's not free. Some battery load remains to keep memory on, but 12 hours just takes my late 2011 MBP done by 10%.
Fix for 17 inch dGPU switch issue
(Tested successfully in both “early” and “late” 2011 17 inch MacBook Pro)
This guide is based on the experience of many users (including me) while trying to fix the very well known issue with AMD dGPU on 17’’ MacBook Pro from 2011 (both early and late):
Step 0) As a starting point I made a clean installation of Sierra (Version 10.12.4) — This is just a step for establishing a common middle ground and is not really needed….
0.1) To do this just download the installer from the App Store and then use “DiskMaker X” to create a bootable installation.
0.2) After the bootable image is created, proceed to turn off your computer and hold the “Alt” or “Options” Key. Select the Sierra installer and proceed with the installation (I format the HDD partition to make a clean install on it)
Note: You might need to do this on another computer. Just buy one of those cheap usb to sata connectors and use it to connect it to another Mac so you don’t risk having your installation failed because of your machine.
Step 1) Prepare a Bootable USB pendrive with a non GUI Linux (Credits to AppleMacFinder)
1.1) Download ArchLinux ISO
You need a working computer for that and a spare CD/DVD/USB drive. Download the latest Arch Linux ISO image from this page - https://www.archlinux.org/download/ , at the time of writing it is archlinux-2017.03.01-dual.iso . Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB: use the great detailed instructions from this page, https://wiki.archlinux.org/index.php/USB_flash_installation_media
1.2) Creating the bootable USB with the .iso:
In macOS
First, you need to identify the USB device. Open /Applications/Utilities/Terminal and list all storage devices with the command:
*) diskutil list
Your USB device will appear as something like /dev/disk2 (external, physical). Verify that this is the device you want to erase by checking its name and size and then use its identifier for the commands below instead of /dev/diskX.
A USB device is normally auto-mounted in macOS, and you have to unmount (not eject) it before block-writing to it with dd. In Terminal, do:
*) diskutil unmountDisk /dev/diskX
Now copy the ISO image file to the device. The dd command is similar to its Linux counterpart, but notice the 'r' before 'disk' for raw mode which makes the transfer much faster:
*) sudo dd if=path/to/arch.iso of=/dev/rdiskX bs=1m
After completion, macOS may complain that "The disk you inserted was not readable by this computer". Select 'Ignore'. The USB device will be bootable.
Step 2) Boot to Linux (Credits to AppleMacFinder):
2.1) Boot to it: insert this CD/DVD/USB to Macbook Pro, hold Option key while booting, choose "EFI boot" (that is your bootable installation media), press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter. If everything is done correctly, you will find yourself at the Linux console! (It takes some time so be patient and wait for the prompt)
2.2) Edit EFI vars: looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a "gpu-power-prefs-..." variable (where ... is UUID of this variable).
2.2-Case 1:
If there is such a variable, its better to remove it with rm.
*) rm gpu-power-prefs-…
In my case the efivarfs has been mounted by default with read/write permissions, but if you are getting the "operation not permitted" message while attempting to rm, it means that in your case efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again (credits to totoe_84 for this valuable addition) (Try this and then try to remove it):
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/
*) rm gpu-power-prefs-…
If this also fails (If you still can’t erase the file) use chattr command to disable file immutability and then erase the file:
*) chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-…”
*) cd /sys/firmware/efi/efivars/
*) rm gpu-power-prefs-…
2.2-Case 2:
The file gpu-power-prefs-… doesn’t exist well then you don’t have to delete it hahaha. (I repaired 2 17 inch models and 1 didn’t have it, so it’s fine)
2.3) Create a new gpu-power-prefs-… file (Original credit mentioned above, https://github.com/0xbb/gpu-switch/blob/master/gpu-switch, Credits to AppleMacFinder):
*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
2.4) Add immutability to the gpu-power-prefs-… file (Credits to AppleMacFinder):
This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances
*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"
2.5) Unmount efivars and reboot (Credits to AppleMacFinder):
Could not unmount efivars if you are inside this directory, so change to the root directory
*) cd /
*) umount /sys/firmware/efi/efivars/
Guarantees that your EFI variables are flushed to efivarfs filesystem, please unmount it safely before rebooting)
*) reboot
3) Eliminate AMD Kexts (Credits to newfield),
Note: You might need to do this every time you do an OS updates, since each update normally writes the AMD Kexts again.
(His words and this also happened to me!: After disabling the dGPU using Arch, normal boot would hang halfway. Although safe boot would work. I wound up having to remove all the AMD kext files in the Terminal in Recovery Console)
Trying to remove them in Single User just gave me sandbox errors. (Summary -> Don’t do it in Single User Mode the one that you boot with Cmd + S)
3.1) So what you have to do is:
If you have FileVault Unlock it first:
Unlock first.
Then Boot into Recovery (“cmd + r”, it will boot without failing, if it fails then repeat step 2 and then after that boot directly into recovery with command + R, I had to do this once because the dGPU got active again after booting into the os with AMD kexts)
*) Boot into recovery mode (Command + r)
*) Start Terminal
*) diskutil cs list (find UUID for drive)
*) diskutil coreStorage unlockVolume UUID
*) cd /Volumes/Macintosh\ HD
*) mkdir AMD_Kexts
*) mv System/Library/Extensions/AMD*.* AMD_Kexts/
*) reboot
(If you only have one storage with 1 partition just use "cd /Volumes/Macintosh\ HD" and the remaining commands after starting the terminal)
Extra STEP), if your PC is now working! Download “steveschow” branch of gfxCardStatus (gfxCardStatus v2.4.3i) or just download the app directly from:
URLS:
https://github.com/steveschow/gfxCardStatus/releases
https://github.com/steveschow/gfxCardStatus
With this application you can even prove that the dedicated GPU can't get activated. Even if you try to change the selected GPU to the dedicated one, it just won't change.
—————
The End!
AND VOILA!!! You have a working 17 inch MacBook Pro. As I said I tested this with an early 2011 and late 2011 17 inch MacBook Pro’s and both are now running (Before they were both dead)
Big thanks to AppleMacFinder, to the makers and contributors of this thread, to gfxCardStatus maker and forkers
I just created an account here to share this, Hope it helps more people!
This worked perfectly (at least it seems so). And it was easier than it looked.
Actually I spent more time trying to get my old linux CD's to work and show similar options. It was so easy with USB drive and your instructions.
Mine is MacBook Pro 15 inch Early 2011 (2.3GHz) with AMD Radeon HD 6750M
Thanks a ton.
Pankaj
This is a bit off topic, but I found that when I use Chrome, my MBP 2011 extremely heats, with CPU temperature going up to 90c (and even more) having the fans in full speed. I guess it's a well-known issue already, but for anyone who is not aware of it - use Safari. Chrome is my preferable browser, but I find that when I'm using Safari, CPU is kept in the 50c range. I had my AMD Radeon reflown, so to keep it from failing again I'm running Macs Fan Control constantly, set to Custom mode, left fan responds to CPU Core 1 (min=45, max=60) and right fan with the same settings for CPU Core 4. GFXCardStatus is loaded by default, showing the temp for GPU Diode in the bar. When I see this value rising above 45c I know I should switch GPUs (from AMD to Intel).
Last edited:
Chrome uses hardware acceleration and Safari does not. Hardware acceleration causes macOS to switch to the Radeon GPU. This is based on my experience with Chrome on a mid-2010 15" MBP with an nVidia 330 GPU.
I was able to fix my MAC OSX as well, but having trouble with bootcamp. I can get in with Safe Mode, but I don't know how to get Windows 7 to point to the integrated graphics, rather than the AMD chip.
[doublepost=1502650858][/doublepost]Used chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" instead (first -i to remove the file, then after prinf with +i to protect it).
Yes, I had to use the same chattr -i command to allow me to gpu-power-prefs... file. Just setting up rw on the folder was not enough.
Thank you all for these amazing solutions! I saved my 15'' MBP 2,2 GHz i7 after the GPU failed for the second time. I hope I can use it for a few more years with the IntelHD 3000 GPU. Since I am really no expert, I hope someone can help me with detailed instructions regarding the heat issue, system backup and reboots :
1. My CPU temp is at 40 C - 48 C idle, 50 C - 75 C while browsing/youtube etc. and peaks at 85 C - 92 C when producing and rendering music/other media. My batterylife has decreased strongly and in connection with higher CPU temps, I am a little worried.
2. Unfortunately, I forgot to back up my system before I applied macfinders solution. Which is the best way to do this in hindsight?
3. Can someone provide a working solution (for 10.10.5 ) for keeping only the Intel GPU in use, after reboots?
I am running Yosemite 10.10.5.
Thank you very, very much!
1. My CPU temp is at 40 C - 48 C idle, 50 C - 75 C while browsing/youtube etc. and peaks at 85 C - 92 C when producing and rendering music/other media. My batterylife has decreased strongly and in connection with higher CPU temps, I am a little worried.
2. Unfortunately, I forgot to back up my system before I applied macfinders solution. Which is the best way to do this in hindsight?
3. Can someone provide a working solution (for 10.10.5 ) for keeping only the Intel GPU in use, after reboots?
I am running Yosemite 10.10.5.
Thank you very, very much!
Last edited:
Disable hardware acceleration for Chrome and Firefox.
1 - Chrome
Menu Chrome (version 60.0.3112.90) or (Command ,) -> Preferences -> Advanced -> System -> Use hardware acceleration when available -> selector gray color (disable) -> restart Chrome.
2 - Firefox
Menu Firefox (version 54.0.1) or (Command ,) -> Preferences -> Advanced -> Use hardware acceleration when available -> unchecked -> restart Firefox
Last edited:
Mine too. Just sleep.
I've turned off Safe Sleep as I've installed SSD to my Mac. Writing 16GB at every sleep is too much.
Hi MikeyN,
I got over excited and applied the original OP's fix - ie. the Arch Linux solution and then moving all the AMD kexts - before reading the rest of the thread. I now realise I should have applied the simpler solution - like yours above or SirMeowington5's (post #528) - because I'm getting the temperature increase and reduced battery life others have mentioned.
The commands I used to move all the AMD kexts were as per AppleMacFinder's original post:
So, after disabling SIP, I booted into single user mode (Command+S) and applied these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot
But now I'd like to move all the AMD kexts back - except for the AMDRadeonX3000.kext - in the hope that the temperature will go down. What commands would you use to accomplish that?
I'll take a stab at it... but I don't really know my way around Terminal. Would these commands below work?
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mv /AMD_Kexts/AMD*.* /System/Library/Extensions/ (I'm hoping this will move all the AMD kexts back to the System/Library/Extensions folder - ?????)
4) sudo mv /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/ (then, I'm hoping this will just move the AMDRadeonX3000.kext to the AMD_Kexts folder - ?????)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - with the returned AMD drivers - will be definitely rebuilt)
8) sudo reboot
If you could please give me some guidance that would be greatly appreciated
It's fantastic that I've got a working Macbook Pro again (thanks to the OP and all contributors) but I'd love to reduce these soaring temperatures and short battery life.
Many thanks
I got over excited and applied the original OP's fix - ie. the Arch Linux solution and then moving all the AMD kexts - before reading the rest of the thread. I now realise I should have applied the simpler solution - like yours above or SirMeowington5's (post #528) - because I'm getting the temperature increase and reduced battery life others have mentioned.
The commands I used to move all the AMD kexts were as per AppleMacFinder's original post:
So, after disabling SIP, I booted into single user mode (Command+S) and applied these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot
But now I'd like to move all the AMD kexts back - except for the AMDRadeonX3000.kext - in the hope that the temperature will go down. What commands would you use to accomplish that?
I'll take a stab at it... but I don't really know my way around Terminal. Would these commands below work?
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mv /AMD_Kexts/AMD*.* /System/Library/Extensions/ (I'm hoping this will move all the AMD kexts back to the System/Library/Extensions folder - ?????)
4) sudo mv /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/ (then, I'm hoping this will just move the AMDRadeonX3000.kext to the AMD_Kexts folder - ?????)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - with the returned AMD drivers - will be definitely rebuilt)
8) sudo reboot
If you could please give me some guidance that would be greatly appreciated
It's fantastic that I've got a working Macbook Pro again (thanks to the OP and all contributors) but I'd love to reduce these soaring temperatures and short battery life.
Many thanks
It would be helpful to know the OS you are are on.
Yosemite gives better temperatures for me but breaks sleep. Sierra is hotter but sleep works.
To quote your planned endeavour, comments apply to while still in single user,
btw: in single user you are root, so every instance of sudo there is superfluous
0) do issue nvram boot-args="-v" # this enables verbose boot to give you a better idea what's going on
1) fsck -fy (to check a disk)
# not a bad idea but also not really needed after a clean shutdown; probably skippable
2) mount -uw / (mount a root filesystem with read/write permissions)
3) mv /AMD_Kexts/AMD*.* /System/Library/Extensions/ (I'm hoping this will move all the AMD kexts back to the System/Library/Extensions folder - ?????)
# If they are there the kexts should be put back. It is paramount that you did not apply any system updates in the meantime. Some guides here also moved ATI-kexts, watch out for them; do an ls -al /AMD_Kexts if unsure and move them back also.
4) mv /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/ (then, I'm hoping this will just move the AMDRadeonX3000.kext to the AMD_Kexts folder - ?????)
# it should.
5) rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
# this is a step I would skip on a first try. The caches are likely not corrupted.
6) mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
# again: if you skipped 5) also skip this one; both are more source of error than necessary.
7) touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - with the returned AMD drivers - will be definitely rebuilt)
# This step is important and needs to finish properly – wait for it to finish. This is difficult to determine in single user. Best to let it sit for a couple of minutes.
8) reboot
The AMD kexts should be all back now to load at boot except the X3000.
Remember: This needs to be put back before system updates.
In this state the X3000 kext is never loaded automatically. But it apparently needs to be in the kernel to help with the temps.
And to control the temps you need to load the kext either manually after boot with
sudo kextload /AMD_Kexts/AMDRadeonX3000.kext
or automate it with for example a LoginHook like update2 in #599.
Please report back on success and whether you applied any of these settings and with what values.
– pmset gpuswitch
– nvram agc
– nvram gpu-policy
– nvram gpu-active
Cf. #659 for these.
[doublepost=1502725813][/doublepost]
To automate the loading of ATIRadeonX3000.kext, I created a script which includes the kextload command and this script is run by launchd during restarts. The launchd plist file to execute the script on boot was placed in /System/LaunchDaemons/
[…]
I also noticed in the Energy Saver control panel that Automatic graphics switching is now unchecked. The checkbox itself is, however, NOT disabled. I haven't checked it and rebooted to see what would happen.
On which OS did you do so? Are there any delays factored in? Care to share that LaunchDaemon?
Regardless what I tried there it always loaded the kext way too soon in the boot process. Thereby locking it all up again.
And I stopped investigating launchd solutions after I found that a LoginHook worked too. (#599)
The PrefPane setting seems to loose all relevance in our newfound setup it seems.
Last edited:
My machine is running Snow Leopard 10.6.8. I didn't use a delay setting.
The following assumes you've successfully completed the steps outlined in post #528. It only automates the last step (loading of a single kext) on restarts.
Create a .sh script containing the kext load command. For Sierra, replace the text ATIRadeonX3000.kext with AMDRadeonX3000.kext:
The script file can be named as desired using the typical format. e.g. com.macrumors.gpu.sh. For convenience I saved this file in the /AMD_Kexts directory.
Create a .plist file with the following content to be processed by launchd:
It's common practice to name this file using the name of the script being executed. e.g. com.macrumors.gpu.plist. Again, save this file in the /AMD_Kexts directory.
To install the .plist file, launch Terminal and execute:
That completes the installation.
Now restart the machine to automatically load the kext. Login and confirm by launching Terminal and execute:
For Sierra, replace the grep parameter ATI with AMD. In Snow Leopard, the command displays four entries including com.apple.ATIRadeonX3000.
To those adept at bash commands, please let me know of any errors or a simpler way of doing this (aside from using crontab's @Reboot).
Thanks @MikeyN. Following your instructions, I've moved all the AMD kexts back to System/Library/Extensions except for AMDRadeonX3000.kext. Then when I manually load AMDRadeonX3000.kext, the temps drop 15-20°C back to normal operating temperature.
However, now I'm getting the sleep issue folks have reported. The computer goes to sleep but, when you wake it, the screen remains black and I have to restart.
If AMDRadeonX3000.kext isn't loaded, sleep will work fine but then there's the temperature issues...
I'm on El Capitan 10.11.6
Just to confirm... in order to run a shell script to load AMDRadeonX3000.kext on boot would these be the correct commands to type into Terminal:
$ sudo mkdir -p /Library/LoginHook
$ sudo nano /Library/LoginHook/LoadX3000.sh
#!/bin/bash
kextload /AMD_Kexts/AMDRadeonX3000.kext
exit 0
$ sudo chmod a+x /Library/LoginHook/LoadX3000.sh
$ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh
I haven't applied any of those settings - pmset and nvram - that you mention above.
Would it be possible for a script to be written that unloads the AMDRadeonX3000.kext when Sleep is initiated and then reloads it when the computer is woken up again?
Many thanks
However, now I'm getting the sleep issue folks have reported. The computer goes to sleep but, when you wake it, the screen remains black and I have to restart.
If AMDRadeonX3000.kext isn't loaded, sleep will work fine but then there's the temperature issues...
I'm on El Capitan 10.11.6
Just to confirm... in order to run a shell script to load AMDRadeonX3000.kext on boot would these be the correct commands to type into Terminal:
$ sudo mkdir -p /Library/LoginHook
$ sudo nano /Library/LoginHook/LoadX3000.sh
#!/bin/bash
kextload /AMD_Kexts/AMDRadeonX3000.kext
exit 0
$ sudo chmod a+x /Library/LoginHook/LoadX3000.sh
$ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh
I haven't applied any of those settings - pmset and nvram - that you mention above.
Would it be possible for a script to be written that unloads the AMDRadeonX3000.kext when Sleep is initiated and then reloads it when the computer is woken up again?
Many thanks
This is strange.
I had the sleep issue on Yosemite. My impression was that ElCap would sleep properly. Here sleep works with Sierra and High Sierra. Upgraded to Sierra just for proper sleep.
## In case you are unfamiliar with nano: <Ctrl>+<x> after exit 0 tells the editor to quit and save
Unknown. I tried to manually unload them twice. All I got were two instant kernel panics.
I might upgrade to Sierra, then, to see if that overcomes the sleep issue.
I could manually unload the AMDRadeonX3000.kext without any issues in El Capitan.
Regards the script you wrote to load AMDRadeonX3000.kext on boot, does your method have any advantages/disadvantages over the .plist method alembic just posted?
Unloading the kext will also crash Sierra here. That might be a caveat for your plans on upgrading. Keep your current install on a bootable backup.
Using launchd would be the more universal, proper way I thought. My launchd daemon was essentially the same as the one just posted.
The only advantage of the LoginHook is that it works here, loading the kext later together with the GUI.
I first tried a different location (/Library/Extensions) and then using the launchd methods for auto loading.
All of them work in loading the kext. But they do it so early in the boot process that the effect is the same as if having the kext in its default place. That means the boot process hangs. Maybe Apple just did more parallizing in the boot process in later OSes. In my setups I would probably need a certain delay introduced into the launchd process.
After all it keeps me wondering why certain machines/setups seem to have
– trouble sleeping,
– have trouble keeping the nvram-fix and
– have trouble unloading the kext.
It looks more an more like OS in question is not that important per se.
The nvram fix stays here, no matter what. Sleep does not work in Yosemite but Sierra and High Sierra. And Kextunloading crashes in Yosemite and Sierra (High Sierra not yet tested for that).