Thank you AppleMacFinder for the solution, I will try it, however I will order the replacement chip. Please confirm that I will be able to restore the original settings, for the chip to be able to run. Thanks
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
- 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
Is anyone else having issues since updating to 10.12.4? I had this working on my Early 2011 MBP for months under 10.12.3.
I re-applied the fix last night (booting arch linux and set the gpu-power-prefs var through the efivars filesystem), and I could boot macOS with the internal GPU occasionally.
Now, even when I can get a successful boot, I still hear capacitors whining (this was my first symptom of a bad discrete GPU, and it means the chip is powered and running). It seems anything that tries to access the discrete GPU immediately locks up the machine. If I quit gfxCardStatus, the mac locks up. If I try to set gfxCardStatus to integrated only, the computer freezes up. Media apps like EyeTV cause it to freeze up too.
Any thoughts? I'm pretty sure the 10.12.4 update put all the AMD kexts back. Do I need to remove those again? The "100% working solution" part doesn't mention that.
I re-applied the fix last night (booting arch linux and set the gpu-power-prefs var through the efivars filesystem), and I could boot macOS with the internal GPU occasionally.
Now, even when I can get a successful boot, I still hear capacitors whining (this was my first symptom of a bad discrete GPU, and it means the chip is powered and running). It seems anything that tries to access the discrete GPU immediately locks up the machine. If I quit gfxCardStatus, the mac locks up. If I try to set gfxCardStatus to integrated only, the computer freezes up. Media apps like EyeTV cause it to freeze up too.
Any thoughts? I'm pretty sure the 10.12.4 update put all the AMD kexts back. Do I need to remove those again? The "100% working solution" part doesn't mention that.
If 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 ) 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!
This worked for me! Now I have my Mac back again!
When I started having this problem it was right after I had updated to the latest MacOS beta(10.12.5 I believe). Is it just chance that my GPU failed right after that update or was there a firmware updated that bricked the GPU? I'm having trouble finding what exactly the 10.12.5 update installed. If that's what happened, is there a way to revert to the previous GPU and/or EFI "firmware"? Does that make sense?
This is a little over my head so I may not be using the correct terms.
It worked like magic, even in the boot screen, amazing. Thanks AppleMacFinder. Somebody can confirm, that if I remove the created power-pref file and I will do a hardware repair, the dGPU will work again?
I'm running Early 2011 17 inch, MacOS 10.12.4
I'm running Early 2011 17 inch, MacOS 10.12.4
Eventually I succeeded too!!!
I recommend removing the .kext files.
I applied the procedure advised by @AppleMacFinder without removing .kext files but when viewing for example a video the system freezed again (trying to switch to dGPU).
Also on reboot the system freezed again on the gray screen.
When I rebooted to ArchLinux I noticed that the file gnu-power-prefs-..... wasn't anymore there, so some process erased it.
After moving the .kext files, resetting Nvram and SMC and applying the procedure by @AppleMacFinder everything worked perfectly.
Many many thanks @AppleMacFinder
I recommend removing the .kext files.
I applied the procedure advised by @AppleMacFinder without removing .kext files but when viewing for example a video the system freezed again (trying to switch to dGPU).
Also on reboot the system freezed again on the gray screen.
When I rebooted to ArchLinux I noticed that the file gnu-power-prefs-..... wasn't anymore there, so some process erased it.
After moving the .kext files, resetting Nvram and SMC and applying the procedure by @AppleMacFinder everything worked perfectly.
Many many thanks @AppleMacFinder
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
(steveschow) and to switch-gpu makers I can’t thank you guys enough as I am so happy to bring both of this incredible machines back to life. With this post I am not trying to take any credit, but as I had 2 machines I run into different issues with both, which could be helpful to others, thats why I was inclined to make “my own” guide and share it with you.
I just created an account here to share this, Hope it helps more people!
(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
(steveschow) and to switch-gpu makers I can’t thank you guys enough as I am so happy to bring both of this incredible machines back to life. With this post I am not trying to take any credit, but as I had 2 machines I run into different issues with both, which could be helpful to others, thats why I was inclined to make “my own” guide and share it with you.I just created an account here to share this, Hope it helps more people!
Last edited:
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)
(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! (Yay!) but is overheating and your vents are going crazy! 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
—————
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 fix works for the 15" also?
If you have the 15 inch MacBookPro with the Nvidia cards and your able to boot into the system but after sometime your machine hangs (because the dGPU goes active). Then I would recommend you just use the gfxCardStatus v2.4.3i program described in "Step Extra" and then select inside the program to only use the integrated GPU.
In the office I have a 2010 15 inch MacBook Pro that has that problem and I fixed it by using the procedure that I just described since you can log into the user, which you can't with the 17 inch models with AMD cards
I have the 15" with the AMD Radeon HD 6490M
It hang on login, can't load OS.
I did try loading HD in an enclosure then booting it up via USB on another machine and trying the gfxcardstatus fix but no luck.
Then you could try it, It could work since both 17 inch MBPros that I fixed had different Radeon Models and the fixed worked in both. Just check that the code after gpu-power-prefs-[this code] matches yours (if it exist). If it does exist, write it down and I would recommend using that one. Still I don't know the ins and out of what it does, so I can't tell you it will work, but still you can always reformat the drive in case something goes wrong.
Last edited:
Can you explain the code thing again please?
[doublepost=1492654141][/doublepost]Also
Has anyone tried realising the GPU with a heat gun?
Failing the EFI and reflowing fix, is their anyway the machine is salvageable?
Do the Chinese make working logic board copies?
Can the parts be re build in another machine ?
Hi AppleMacFinder
I'm having exactly the same problem. I'm booted from the archlinux live usb as root. I successfully unmount efivarfs and then remounted it - this about the 6th time of trying. But when I try to write the file and what I get id zsh: invalid argument: /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30fg
And I seem to be stuck at this point. I've reset the SMC and zapped the pram but still no luck.
Luckily my screen MBP 8,2 isn't distorted: it's just got the external monitor problem and won't go to sleep. Machine runs a little bit hot. I was hoping that this would enable me to use integrated graphics which would be better than what I have. But it looks like that's not to be.
By the way, last night I had a same file in efivarfs as you last night but after resetting the SMC and zapping thr pram that appeared to have vanished today when I boot into archlinux,
[doublepost=1492957060][/doublepost]I worked out that i was making a simple erroe in the file name cause by the font Macrumour uses and my low level dislexia. Once i realised that the last character in the pintf file was a 9 and not a g AppleMacFinder's fix worked perfectly and I'm now using the MacBookPro 8,2 on ingegrated graphics with no noticeable problems. Both Photoshop and graphics intensive games work without problem. Haven't really noticed not using the AMD graphics unit at all.
[doublepost=1492957552][/doublepost]
If 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 ) 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!
Hi Having posted that I was having problems on Friday - I managed to use the above fix perfectly when I realised the last character in the printf file name was a 9 not a g.
It worked and I'm working on integrated graphics and not really noticing any performance deficit compared with the AMD Radion graphics. Both Photoshop and graphics intensive games work perfectly without problems.
Kudos AppleMacFinder. I thought there must away to enforce this I didn't realize it would be so far down at the machine level. Thank you very much
Anyone tried this
https://github.com/0xbb/gpu-switch
"Please note that only source code is there so Xcode is requred to compile the binary. The application runs from terminal, reportedly uses the same code as gfxCardStatus but writes the setting into NVRAM(PRAM) so machine remains switched to internal GPU on next boot(s)/wake(s)"
https://github.com/0xbb/gpu-switch
"Please note that only source code is there so Xcode is requred to compile the binary. The application runs from terminal, reportedly uses the same code as gfxCardStatus but writes the setting into NVRAM(PRAM) so machine remains switched to internal GPU on next boot(s)/wake(s)"
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)
(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! (Yay!) but is overheating and your vents are going crazy! 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. For the heating issue I just left it on "dynamic switching" and haven't had any problem (Maybe you will need to restart once. And remember to leave it as a launch app when you log in)
—————
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 for me. The initial "fix" that I did turned out to be just my dGPU coming back to life for a brief moment that by cheer chance happened to be when I was messing around with the EFI. It's real glitchy and sometimes it would work for a day or two and then give me the artefacts again. I tried just doing the EFI-fix which didn't help, and booting in single user mode wouldn't let me remove the kext-files. But this worked, and now it's up and running again and the GPU seems to be permanently disabled.
I did however update the OS after initially applying the fix, which wrote new kext files. I simply redid the procedure and it's all working. I'm using a 15" MBP from early 2011, with the AMD 6750.
Hi Team,
Hopefully someone can give me a couple of pointers.
I made the boot USB from windows using TransMac or MacTrans, it was an .iso image.
Booted to Linux successfully.
Think I followed the codes correct (made a couple of mistakes along the way)
Reboot brings me Recovery mode, which I take as a great sign as my machine wasn't previously able to access recovery.
I select boot from HD, restart,
Now it's hanging on Apple logo with half a progress bar.
Whereas before it would wait till I sign in to show the progress bar and hang.
Any ideas are most welcome!
Hopefully someone can give me a couple of pointers.
I made the boot USB from windows using TransMac or MacTrans, it was an .iso image.
Booted to Linux successfully.
Think I followed the codes correct (made a couple of mistakes along the way)
Reboot brings me Recovery mode, which I take as a great sign as my machine wasn't previously able to access recovery.
I select boot from HD, restart,
Now it's hanging on Apple logo with half a progress bar.
Whereas before it would wait till I sign in to show the progress bar and hang.
Any ideas are most welcome!
Attachments
Just did the process again because i saw the which operation not permitted.
went through better, there was no confirmation after each line, just skips straight down to the next terminal without confirmation. seemed like it worked though.
I also disabled SIP and moved amd.kexts
For some reason I can access Recovery mode and safe mode now when i couldn't before but its still not loading regularly
which operation not permitted.went through better, there was no confirmation after each line, just skips straight down to the next terminal without confirmation. seemed like it worked though.
I also disabled SIP and moved amd.kexts
For some reason I can access Recovery mode and safe mode now when i couldn't before but its still not loading regularly
Attachments
Last edited:
Hi!
Just registered to say thank you, AppleInsider, it seems like it's working well and I can still use apps like Illustrator or Lightroom. Well done for the work.
I think this post needs to be share A LOT, on other forums where people are desperate and don't know that they can give life back to their machines. Spread the post!
Oh, and juste a note for myself :
Apple : NEVER again.
Just registered to say thank you, AppleInsider, it seems like it's working well and I can still use apps like Illustrator or Lightroom. Well done for the work.
I think this post needs to be share A LOT, on other forums where people are desperate and don't know that they can give life back to their machines. Spread the post!
Oh, and juste a note for myself :
Apple : NEVER again.
You could set a "temporary" password like qwerty - its almost the same as "no password", very easy for your friends to remember, and it will allow you to run dd and other commands which require a password for their execution
That's strange. I have never had to reapply this fix, even after installing the OS X 10.11.6 update. Maybe you have discharged your computer and it lost the variable values, or maybe this fix is more stable on 10.11.x El Capitan than on 10.12.x Sierra, or something else - I don't know... In any case, try completely wiping the cache and history of your web browser to return it to the default state
Sorry for my late reply! According to https://github.com/0xbb/gpu-switch/blob/master/gpu-switch , you will be able to restore the original settings: by removing this EFI variable and creating it again with \x07\x00\x00\x00\x00\x00\x00\x00 value instead of \x07\x00\x00\x00\x01\x00\x00\x00 value. Alternatively you could just remove this variable and see what happens
Of course you need to remove the AMD kexts - if they came back with 10.12.4 update
The last update for MBP 2011 EFI firmware was several years ago, it is difficult to downgrade it to its' previous version - and I don't see any point in doing so
It could be that 10.12.5 update includes the new AMD kexts and they have been installed. If that is true, you need to remove them again. In short - if anything breaks, repeating a fix should fix the things
2011 Macbook Pro 15" with discrete GPU = 2011 Macbook Pro 8,2 - and the thread title says this fix works for 8,2 . But in theory, it should work for any MBP with integrated+discrete GPU combination, maybe even for those which have discrete NVIDIA instead of discrete AMD
It is interesting that just using gfxCardStatus solves a problem for MBPs with discrete NVIDIA , sadly gfxCardStatus can't solve a problem for MBPs with discrete AMD - so this EFI variable fix is required
Heating the GPU with a heat gun could work, but I can't promise that it will be a permanent fix - because of Apple's bad solder quality eventually it will break again, but nobody could tell when: after a couple of hours/days/months/or years . Also you need to be careful - don't overheat the neighbour parts! It is recommended to cover everything with aluminium foil, except a GPU chip, before using a heat gun. Of course its better to either do BGA reballing with good solder, or GPU replacement, but these things are hardly doable at the domestic conditions, especially for the people with no repair experience
EFI fix should work eventually, I am very sad reading that it is not working for you yet... If you are tired with EFI variable fix and have some spare money, here is the alternative solution - quoted from my 1st message of this thread:
There are even some Chinese motherboard repair services - for example, http://www.aliexpress.com/item/Prof...her-Board-Quad-Core-i7-2-0Ghz/2024020852.html and http://www.aliexpress.com/item/Prof...Ghz-17-Mother-Board-MC024LL-A/2023462680.html , but I guess they are useful only for those people who live in the countries with a very high labour costs and it is too expensive for them to repair it locally
I do not know if the Chinese are making the working logic board copies ( I think they don't ),
but they have three possible items in their stocks:
1) completely new 2011 MBP motherboards - Apple always orders to manufacture more motherboards than MBPs, so that some motherboards could be used as the replacement parts
2) used 2011 MBP motherboards extracted from a broken MBP which had another problem - e.g. someone has damaged a screen of their MBP, and because the replacement price for a screen is too high, they decided to tear down this MBP and sell its' parts separately. These motherboards have a GPU timebomb because it has never been fixed on them
3) used 2011 MBP motherboards extracted from a broken MBP with repaired GPU - probably its' rare
In any case, the MBP replacement motherboard costs like $500 - so its much more efficient to replace only the failed component (GPU) rather than the whole motherboard
Of course the parts could be re-used, but I think its more efficient to somehow fix this MBP - either by EFI variable fix or GPU reflowing/replacement - rather than sell it for parts
My EFI variable fix instructions are partially based on a file from this repository - https://github.com/0xbb/gpu-switch/blob/master/gpu-switch . So yes, we all tried this
Under Windows, the Rufus utility is recommended for making the Linux bootable USBs, but maybe TransMac could be used too...
Problem with this EFI variable fix is that even a small mistake - like, typing g instead of 9 as the last character in the printf command - makes it fail to work
Looks like you somehow booted to Recovery with AMD kexts disabled, but after rebooting they got loaded again...
Just did the process again because i saw the
went through better, there was no confirmation after each line, just skips straight down to the next terminal without confirmation. seemed like it worked though.
I also disabled SIP and moved amd.kexts
For some reason I can access Recovery mode and safe mode now when i couldn't before but its still not loading regularly
Seems like you are close to a target, but something is preventing you to achieve a full success. Are you sure that you have properly removed the AMD kexts, and that the kexts cache has been rebuilt as well? Maybe the kext cache still contains the AMD kexts, so you need to force rebuilding this cache to finalize their removal
Please try again this part of my 1st message:
Last edited:
Thanks Apple Mac finder for taking the time to respond!
What I'm doing now is partitioning the HDD in 3, ubuntu, OS X and windows.
Hopefully one of these should work.
I think from memory when applying the EFI fix I wasn't able to remove GPU-power-pref even though I attempted to load rw permissions.
I was also a little confused by the first chattr -I line where is says skip this command.
I attempted it, and also attempted another one someone wrote on the forum where I'd started chattr -i and ended in GPU-power......
Unsure of what went wrong :/
What I'm doing now is partitioning the HDD in 3, ubuntu, OS X and windows.
Hopefully one of these should work.
I think from memory when applying the EFI fix I wasn't able to remove GPU-power-pref even though I attempted to load rw permissions.
I was also a little confused by the first chattr -I line where is says skip this command.
I attempted it, and also attempted another one someone wrote on the forum where I'd started chattr -i and ended in GPU-power......
Unsure of what went wrong :/
As I already said this procedure make me fix the Macbook and I am really happy for it.
But I notice that fans run a lot more than before (I am working in a 20 °C room using just Safari).
Does it only happen to me?
But I notice that fans run a lot more than before (I am working in a 20 °C room using just Safari).
Does it only happen to me?
Thanks to the TO for his excellent work.
I want just to add another ADDITIONAL possible "Solution" for the problem, which is rapidly done in a few minutes under OSX AND (!) at least IMHO a good additional protection of a not already dead GPU:
explaining my situation at the beginning:
In our family we own some cMBP 15" 2011 and two of 2012.
One of the 2011 had already a MB-replacement (still working correctly after that, *knocking on wood*) and just some weeks ago even one of the 2012 ones showed the typical signs of a dying dGPU - gladfully, just reversible, for a while and so being just in condition of "going soon to die, but still alive" . The problem: until now, apple is NOT accepting the 2012 MBP for a replacement.
FIRST of the problems of dGPUs seems to be a not_too_Intelligent_design_of_dGPU-cooling for me:
Seemingly, both fans are blowing air in a common channel that FIRST cools the CPU, followed by cooling of the dGPU - but with the same air, already heated up by the cooling of the CPU!
a really idioxxx way to "cool":
After burning yourself accidently, you for shure cool yourself with cool water - but Jonathan Ive seems to prefer boiling water to do so...
SECOND problem is not only apple´s policy of "function follows form" (too little volume of the notebook for cooling) but also "cooling follows silence" :
The fans start far too late to cool and even then they cool not efficient enough, meaning too little upm.
So - I installed two years ago MacFanControl.
Set one of the fans reacting on temperature of core 2 of CPU (which is at least in my MBP the hottest core of all 4)
Set the other fan reacting on temperature of PECI GPU (which ist always at least in my MBP the hottest part of the dGPU-Complex)
Nevertheless this short time of dGPU_in_Danger some weeks ago showed that the OLD SETTING I did were not at all sufficiently protecting the dGPU. I did not augment the cooling mode aggressive enough higher than the standard reaction implemented by apple, especially the basic rpm.
NOW, as limit to go higher than the basic rpm of 2000 in the original apple-standard, I did set the lower limit for both CPU and dGPU to 47° C, the maximum limit to 67°C. so - instead of resting most of the time at minimum rpm in "apple standard mode", it rests mostly at still absolut SILENT 3000 rpm = 50% more basic cooling!
Which is pretty aggressive, permitting rapid "exploding" rpm even higher, IMMEDIATELY when heating up, but - in preventing too high temperatures - getting rapidly down again after a short time, if CPU/dGPU not too busy. And so reacting far much faster and staying at higher rpm than in the "standard apple mode" the which is well known to lead to our common problem with dead dGPUs.
Since again changing recently my MacFanControl-settings to this even more aggressive approach - there was never a single sign of attainted or "nearly dying dGPU" - although doing some hard tests with work fully charging both CPU and dGPU with lots of work and so heating up.
bottom line for me:
To protect your beloved cMBP and counterweight the foolish design for cooling dGPU in MBPs there are a handful of different possibilities:
1) The method of the TO
but also
2) further stabilizing and protecting methods like a aggressive setting in MacFanControl.
Advantage: Done in a few minutes.
Firstly, you can let it in "automatic mode", thus just being able to regard and control regually dGPU temperature to understand the problem of "undercooling" of the dGPU and its soldering problems... Then, in a second step, you might take the nevertheless existing risk of your personal settings - BUT think very well about your settings. And control well your temperatures at the beginning. For my own cMBP, this works very fine.
AND:
3) shurely also an effective, but risky and demanding know-how is the modification and replacement of the thermal paste used by apple.
As already shown in classic MacPros, the assembly of the CPUs with too much and not_yet-state_of_the_art thermal_paste (and this in addition neither well done) is - if well done - shurely also a good additional protection. Some people here in the forum did this already also in the cMBP and reported success: lower temperatures of processors
I like the cMBP of 2011 and especially 2012 a lot - easy and much less costly replacement/upgrading of RAM, SSD, battery, the very last one with option of a glossy-free screen,.... the very last one really ergonomic an more or less customer-friendly MBPs, but with a fatal mistake in design.
I´ll do everything to protect them to use them as long as even possible.
edit:
Can anybody confirm definitely a common cooling-line of both fans in the cMBPs?
https://forums.macrumors.com/threads/question-about-cooling-system-for-mbp-2011-and-2012.2043420/
thank you in advance
I want just to add another ADDITIONAL possible "Solution" for the problem, which is rapidly done in a few minutes under OSX AND (!) at least IMHO a good additional protection of a not already dead GPU:
explaining my situation at the beginning:
In our family we own some cMBP 15" 2011 and two of 2012.
One of the 2011 had already a MB-replacement (still working correctly after that, *knocking on wood*) and just some weeks ago even one of the 2012 ones showed the typical signs of a dying dGPU - gladfully, just reversible, for a while and so being just in condition of "going soon to die, but still alive" . The problem: until now, apple is NOT accepting the 2012 MBP for a replacement.
FIRST of the problems of dGPUs seems to be a not_too_Intelligent_design_of_dGPU-cooling for me:
Seemingly, both fans are blowing air in a common channel that FIRST cools the CPU, followed by cooling of the dGPU - but with the same air, already heated up by the cooling of the CPU!
a really idioxxx way to "cool":
After burning yourself accidently, you for shure cool yourself with cool water - but Jonathan Ive seems to prefer boiling water to do so...
SECOND problem is not only apple´s policy of "function follows form" (too little volume of the notebook for cooling) but also "cooling follows silence" :
The fans start far too late to cool and even then they cool not efficient enough, meaning too little upm.
So - I installed two years ago MacFanControl.
Set one of the fans reacting on temperature of core 2 of CPU (which is at least in my MBP the hottest core of all 4)
Set the other fan reacting on temperature of PECI GPU (which ist always at least in my MBP the hottest part of the dGPU-Complex)
Nevertheless this short time of dGPU_in_Danger some weeks ago showed that the OLD SETTING I did were not at all sufficiently protecting the dGPU. I did not augment the cooling mode aggressive enough higher than the standard reaction implemented by apple, especially the basic rpm.
NOW, as limit to go higher than the basic rpm of 2000 in the original apple-standard, I did set the lower limit for both CPU and dGPU to 47° C, the maximum limit to 67°C. so - instead of resting most of the time at minimum rpm in "apple standard mode", it rests mostly at still absolut SILENT 3000 rpm = 50% more basic cooling!
Which is pretty aggressive, permitting rapid "exploding" rpm even higher, IMMEDIATELY when heating up, but - in preventing too high temperatures - getting rapidly down again after a short time, if CPU/dGPU not too busy. And so reacting far much faster and staying at higher rpm than in the "standard apple mode" the which is well known to lead to our common problem with dead dGPUs.
Since again changing recently my MacFanControl-settings to this even more aggressive approach - there was never a single sign of attainted or "nearly dying dGPU" - although doing some hard tests with work fully charging both CPU and dGPU with lots of work and so heating up.
bottom line for me:
To protect your beloved cMBP and counterweight the foolish design for cooling dGPU in MBPs there are a handful of different possibilities:
1) The method of the TO
but also
2) further stabilizing and protecting methods like a aggressive setting in MacFanControl.
Advantage: Done in a few minutes.
Firstly, you can let it in "automatic mode", thus just being able to regard and control regually dGPU temperature to understand the problem of "undercooling" of the dGPU and its soldering problems... Then, in a second step, you might take the nevertheless existing risk of your personal settings - BUT think very well about your settings. And control well your temperatures at the beginning. For my own cMBP, this works very fine.
AND:
3) shurely also an effective, but risky and demanding know-how is the modification and replacement of the thermal paste used by apple.
As already shown in classic MacPros, the assembly of the CPUs with too much and not_yet-state_of_the_art thermal_paste (and this in addition neither well done) is - if well done - shurely also a good additional protection. Some people here in the forum did this already also in the cMBP and reported success: lower temperatures of processors
I like the cMBP of 2011 and especially 2012 a lot - easy and much less costly replacement/upgrading of RAM, SSD, battery, the very last one with option of a glossy-free screen,.... the very last one really ergonomic an more or less customer-friendly MBPs, but with a fatal mistake in design.
I´ll do everything to protect them to use them as long as even possible.
edit:
Can anybody confirm definitely a common cooling-line of both fans in the cMBPs?
https://forums.macrumors.com/threads/question-about-cooling-system-for-mbp-2011-and-2012.2043420/
thank you in advance
Last edited:
Thanks AppleMacFinder. After a full day of troubleshooting and researching I finally found your post. I'm sure I'm getting close to resolving this.
Just struck one hitch with the process. When I issue the CHATTR command is comes back with NOT FOUND. It's like the command is not available on the Linux Distro, neither does the LSATTR work.
I pushed on with the process but when I tried to reinstall the OSX instead of going to a whitescreen like previously it freezes now with the Apple logo and a frozen spinning wheel.
Do I need to add those commands to the Arch Linux Boot image? Thanks for your help.
Just struck one hitch with the process. When I issue the CHATTR command is comes back with NOT FOUND. It's like the command is not available on the Linux Distro, neither does the LSATTR work.
I pushed on with the process but when I tried to reinstall the OSX instead of going to a whitescreen like previously it freezes now with the Apple logo and a frozen spinning wheel.
Do I need to add those commands to the Arch Linux Boot image? Thanks for your help.
1.Hello. Pls help me. When i do command printf have issue: write effor : invalid argument
Pls see a attach picture and help me
2. Nomodeset with space before or no?
Thank
[doublepost=1493793919][/doublepost]
![IMG_5835.JPG]( "IMG_5835.JPG")
Pls see a attach picture and help me
2. Nomodeset with space before or no?
Thank
[doublepost=1493793919][/doublepost]