Resolved Force 2011 MacBook Pro 8,2 with failed AMD GPU to ALWAYS use Intel integrated GPU (EFI variable fix)

Discussion in 'MacBook Pro' started by AppleMacFinder, Mar 18, 2017.

  1. nonlen macrumors newbie

    Mar 29, 2014
    OK, thanks Sergio. This makes sense. Did you disable SIP before the hack? Or is there anything else that should be done, other than you listed, before or after the hack?
  2. MikeyN macrumors regular


    Jul 26, 2017
    Alas, these tend to be a bit outdated. Available settings should be up to date in man pmset. Alas, these are also somewhat shady.

    The prime example for that is the seemingly relevant to this thread setting gpuswitch. That it now does not work for us anymore might be unsurprising. What surprised me is that changes to this setting are not reflected in System Preferences, where the checkbox is still selectable.
    But that it is not in the manpage is disturbing. pmset -g does not list the variable destroyfvkeyonstandby, yet the manpage does.
    The settings available should be all listed with either pmset -g or within the manpage. In both cases the lists are incomplete.

    But with our hack in place, I notice that there are some things left wanting. And some pmset value or combination might indeed be beneficial.

    Yosemite has trouble waking up; for me: always.
    Yosemite has trouble shutting down; it is very slow, apparently sometimes really hanging.
    El Capitan has now reports to the same effect.
    Sierra shuts down quickly, wakes up as designed. Well, most of the time.
    Longer sleeping sometimes results in the same dark screen hang on waking. (10% of all tries, seems duration related, can't be sure yet.)
    This only talks about 'sleeping' since hibernate immediately didn't give any differing results.

    That looks to me as if the "standby" feature kicked in during the sleep period. Despite that this feature is not supported on this hardware!

    Experimenting with the settings for pmset, I got unsatisfactory results so far for using the default values as well as setting standbydelay and standby to 0.

    Any further ideas or findings?

    That sounds you are in the same situation: #836.
  3. SergioF macrumors newbie

    Aug 25, 2017
    Algoz, Portugal
    No need to disable SIP for the hack to work. If you use the external drive solution to remove the kext then that is all that is needed.
    Since my last post I have upgraded one of the MBP from Yosemite to Sierra using an external disk but after the upgrade you need to use the external disk again to remove the kext. The same goes when you do system updates for Sierra, it will re-install the offending kext which you have to remove it so that the system can boot up. The NVRAM hack wasn't affected during the upgrade or the update.
  4. saldin, Aug 30, 2017
    Last edited: Aug 30, 2017

    saldin macrumors member

    Jul 30, 2012
    A friend had a Late-2011 MBP running Yosi (mine is an Early-2011) which has a garbled screen of horizontal red lines. He brought it to my house and I applied the hack for him and the screen is readable once again. The horizontal lines disappeared as if by magic!

    Thank you to all the wonderful people who have contributed so much! I've thanked MikeyN plenty, but I effusively thank AppleMacFinder and nsgr as well for having researched the original solution and improving on it! I'm truly sorry if I'm missing contributors; I haven't thoroughly read every post, but I thank you all!
  5. Schmye Bubbula, Aug 30, 2017
    Last edited: Aug 30, 2017

    Schmye Bubbula macrumors member

    Schmye Bubbula

    Jul 24, 2009
    Early-2011 15" MacBook Pro, ElCap.
    Took a week to read this whole thread.
    All methods have worked for me; I move the AMDRadeonX3000.kext, but I suffer the sleep & shutdown problems.
    I have this AppleScript applet set as a login item:
    do shell script "kextload /AMD_kexts/AMDRadeonX3000.kext" password "[my system password insecurely in cleartext]" with administrator privileges
    I was getting ready to install SleepWatcher 2.2 to automate doing a kextunload upon every sleep, but doing it in Terminal beforehand to test always gave me a kernel panic. I don't recall this being mentioned before here, so can anyone confirm? Any other thoughts on dealing with the sleep/reboot hangs? Higher temp vs. no sleep & shutdown woes tradeoff is untenable for my situation (I'm not the only user of this Mac, and others won't understand).
  6. MikeyN, Aug 30, 2017
    Last edited: Aug 30, 2017

    MikeyN macrumors regular


    Jul 26, 2017
    Neat AppleScript solution. Although a bit less ideal security wise, as you noted. Nevertheless: inventive new finding. If the security concerns you, take a look at the system-LaunchAgent and LoginHook solutions as well.

    As I just noted a few posts above: I saw the exact wake-from-sleep issues on Yosi – always – and now there are several reports here indicating that ElCap also might have problems. But this seems somehow inconsistent. Others on ElCap seem to live a trouble free life with this hack applied. I wonder were the culprit for this lies?

    However, I also saw and reported (several pages back) that kextunload for X3000 drives an immediate kernel-panic, on all OS versions. I tried several options to the command or unloading even more kexts I thought related, to save kextd the headaches it seems to get from this. No success. So far.

    I didn't know about SleepWatcher. Thanks for mentioning this. That may help in automating tests for this nuisance.

    For me, the only solution, 'partly perfect', was to ditch Yosi and go to Sierra. Very reluctantly. But after testing Sierra's behaviour for waking – with the kext loaded after a delay – I concluded it was worth it for getting waking back.
    Unfortunately it works not 100% perfect. The last several days it worked for any amount of time sleeping. And just this night it went bonkers again. Black screen from wake, forced reboot.
    Waking on Sierra seems to have a success rate close to 95% for me. (Just to throw in an unscientific number.)

    So, if Sierra might be an option:
    get another drive/partition and make a "clean install" of first ElCap, test this for waking issues, then make a clean install of Sierra, test that for waking issues. Then decide and follow that decision. I mention both, since somehow I am pondering the possibility that it might improve on fresh and clean installations.
    And please report your findings here.
  7. saldin macrumors member

    Jul 30, 2012
    Excellent solution! I created an app from the script, set it as a login item with the hidden check on, and it works, but asks for my password on every boot because "it needs permission to make changes". Did I make a mistake or is that the expected behavior?

  8. MikeyN macrumors regular


    Jul 26, 2017
    Why not try this pw-less solution from #599 (adapt the paths to your settings):

    Update 2:
    $ sudo mkdir -p /Library/LoginHook
    $ sudo nano /Library/LoginHook/

    kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
    exit 0

    $ sudo chmod a+x /Library/LoginHook/
    $ sudo defaults write LoginHook /Library/LoginHook/

    If you still really need to go the app route you might have to set the binary to run as root. Since if it isn't, then what you saw is expected behaviour. LoginHooks are executed as root automatically.
  9. Schmye Bubbula macrumors member

    Schmye Bubbula

    Jul 24, 2009
    MikeyN, for me, the question of what happens coming out of sleep doesn't arise: my hang occurs when invoking sleep. (And when invoking reboot or shutdown.)

    I don't get another prompt for my system password (were you putting your password within quotation marks?—it needs to be... I've edited my earlier post #855 thusly), but you could try this instead:
    do shell script "echo yourSystemPasswordInsecurelyInCleartext | sudo -S sh -c \"kextload /AMD_kexts/AMDRadeonX3000.kext\" "

  10. nonlen macrumors newbie

    Mar 29, 2014
    Hi, I tried to do this and didn't succeed. I did #2, #3 as described above. I tried to boot from an external drive (El Capitan, AMDRadeonX3000.kext removed) but for some reason it didn't boot to OS X but went to, "my guess??? single user mode???? Sorry, I'm totally new with these....So I removed the AMDRadeonX3000.kext by removing HD from MBP and connecting it to an other mac. Then installed HD back to my MBP, tried to boot but again, no success and white screen. Well, then I did
    nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

    and managed to open MBP again but still can't shut it down and boot. Should I try some other approach? Or try this again? Any thoughts?
  11. nsgr, Aug 30, 2017
    Last edited: Aug 30, 2017

    nsgr macrumors 6502

    May 22, 2017
    Unfortunately Apple's manuals are not very complete. Examples are hidden boot-args (agc, agclog, etc). That is why there are several links (pmset).

    The kextunload manual has other options that do not fully unload the kext. Tests, tests and more tests.

    The kextunload manual also says to use kextlog (boot-args) to have a more complete report on load and unload kexts.

    man kextunload

    man kext_logging

    Kernel Panic:

    sudo kextunload /DisableExtensions/AMDRadeonX3000.kext


    sudo kextunload /System/Library/Extensions/AMD6000Controller.kext

    If the person does a lot of testing, then I recommend installing the Mac OS system on a USB stick. And open the Macbook Pro and disconnect the Hard Disk or SSD (SATA connector).

    I lose a hard disk after many kernel panics and force shutdown (press button power).

    It is better to lose a pen drive than it costs cheap than to lose a Hard Disk or SSD that costs more. Or use an old hard disk or SSD that you were not using.

    After this episode (Lose the hard disk) I finally entered the world of SSDs.


    Install & Run macOS Sierra on External SSD or USB Flash Drive

  12. MikeyN, Aug 30, 2017
    Last edited: Aug 30, 2017

    MikeyN macrumors regular


    Jul 26, 2017
    Excellent advice.
    And that's what I did up to now, but without disconnecting the internal drive. Although I would really prefer to have a bootable Thunderbolt drive to do that external booting thing. Sadly, on TB all external disks go through a hub and that prevents booting with TB-speed. When I did get all those KPs HFSplus CoreStorage recovered quite robustly. Have you forced yours to plain HFSplus? But I also got really belt and suspenders there and fscked regularly.

    Most panics were so immediate that no log survived on disk. There was then only the occasional NVRAM-litter.
  13. mikecwest macrumors 6502a


    Jul 7, 2013
    It seems that I have to at least once a day, run the "nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00" command again.

    Is it possible to add this to my boot-args, so that it just happens, EVERYTIME I boot/reboot?
    --- Post Merged, Aug 31, 2017 ---
    It seems I have to do this at least once daily, it is possible to have " nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 " as part of the boot-args?
  14. nsgr, Aug 31, 2017
    Last edited: Aug 31, 2017

    nsgr macrumors 6502

    May 22, 2017
    When I have a kernel panic, then I enter the boot single user and do the fsck -fy and then mount -uw / to see if it has orphan files. Then reboot to enter normal boot.


    Pendrive format: OS X Estend Journaled - HFSplus

    Pendrive Scheme: GUID Partition Map
    --- Post Merged, Aug 31, 2017 ---
    User Savroula post #594:

    sudo nvram gpu-power-prefs=%01%00%00%00
    sudo reboot

    The variables gpu-policy and gpu-active stand outside the boot-args. I think the variable gpu-power-prefs is also out of boot-args.

    The boot-args are connected to the Mac OS operating system. The gpu-power-prefs must run before normal boot or before the filevault screen boot (boot encrypted).

    I did a test with the variable gpu-policy and then I saw with ArchLinux that there were two gpu-policy variables but with different GUIDs.

    My test with gpu-active

    1 - sudo nvram FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-active=%01%00%00%00

    2 - sudo nvram gpu-active=%01%00%00%00

    3 - Enter ArchLinux and view /sys/firmware/efi/efivars with ls command - result:



  15. mikecwest macrumors 6502a


    Jul 7, 2013
    #865 I just have to do it every time it messes up? I have it set with a bash file, so it’s a bit easier than typing out all of it.
  16. nsgr, Aug 31, 2017
    Last edited: Aug 31, 2017

    nsgr macrumors 6502

    May 22, 2017
    When you use nvram with variable gpu-power-prefs, then this variable is stored in the EFI partition.

    sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00


    sudo nvram gpu-power-prefs=%01%00%00%00

    Test these two nvram gpu-power-prefs together and see if it resists reboot and shutdown.


    0 - Boot Single User (Command + S)

    1 - sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

    2 - sudo nvram gpu-power-prefs=%01%00%00%00

    3 - reboot

    4 - normal boot -> login graphical interface -> reboot with Terminal -> sudo shutdown -r now


    normal boot -> login graphical interface -> poweroff with Terminal -> sudo shutdown -h now

    5 - View if resist gpu-power-prefs

    Update 2:

    Yes, bash file is easier and faster.
  17. nsgr macrumors 6502

    May 22, 2017
    Update 3:

    1 - Boot ArchLinux and delete gpu-power-prefs-fa4ce... and gpu-power-prefs-7c436...

    2 - Reboot

    3 - Reset NVRAM (Command + Option + R + P)

    4 - Boot Mac OS in Single User Mode (Command + S) with red screen and white stripes

    5 - sudo nvram gpu-power-prefs=%01%00%00%00

    6 - Reboot -> after reboot remain red screen and white stripes

    7 - Boot ArchLinux and view gpu-power-prefs + GUID with red screen and white stripes. ls command in /sys/firmware/efi/efivars result:


    8 - Reboot

    9 - Boot Mac OS in Single User Mode (Command + S) with red screen and white stripes

    10 - sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

    11 - Reboot

    12 - Now the Screen is normal (no red screen no white stripes)

    13 - Boot ArchLinux and view /sys/firmware/efi/efivar with ls command:


  18. pheimbach macrumors newbie

    Sep 1, 2017
    I want to thank all the contributors of this thread. My early 2011 15" Macbook pro work fine now.
    I don't have the "sleep" problem. My mac always comes back without a problem. I'm running Sierra 10.12.6
    I have noticed that my Mac's battery life is completely screwed up now. As if it was running on the AMD.
    I normally got around 7 hours of battery life. Now I hardly get 2,5 hours; like it used to do when running on the AMD.
    Has anyone experienced this too?
  19. rlebleu macrumors member


    Jul 1, 2017
    Are you loading AMDRadeonX3000.kext after logging in? In my case, battery draw dropped by at least 30%, and temperature dropped 20c.

    That file was removed (relocated) from the extensions folder to prevent it being loaded at boot time. After you have logged in, it should be reloaded...

    sudo kextload /Wherever you moved it to from the extensions folder/AMDRadeonX3000.kext
  20. pheimbach macrumors newbie

    Sep 1, 2017
    Really? Does that mean I have to remove it again before reboot/shutdown? And do I have to disable SIP again?
  21. rlebleu macrumors member


    Jul 1, 2017
    No need to remove it or move it. Initial steps of this fix required you to move it from the extensions folder to another folder... when I did it I moved to AMD_Kexts. If you reboot, you will have to reload again - yes. In my case, I very seldom reboot. I just close the lid, and it goes into safe sleep. Open the lid and carry on from where were...
  22. pheimbach, Sep 1, 2017
    Last edited: Sep 1, 2017

    pheimbach macrumors newbie

    Sep 1, 2017
    Okay. I will try that. Thanks! :)
    Do you have to remove the kext when you reboot?
  23. nonlen macrumors newbie

    Mar 29, 2014
    There seems to be too many alternative ways of trying to fix this...I believe there are many of us "inexperienced" MBP 2011 users who would really appreciate if someone could write the list of the whole procedure from A to Y that includes everything that needs to be done. At this moment, at least for me, there are too many guidelines to follow....
  24. MikeyN, Sep 1, 2017
    Last edited: Sep 1, 2017

    MikeyN macrumors regular


    Jul 26, 2017
    There is not *one* guide to write up. Many roads lead to Rome. The best option would be if AppleMacFinder would update the first post of this thread pointing to the best alternatives.

    Anyway. Even if this post now will quickly drown in the sheer length of this thread, I think this is currently one of the better guides:

    #####__ The Guide __#####

    This guide assumes that you run a stock system. Problem just occured. That means:
    This guide assumes that all kexts are still in their default location /System/Library/Extensions.
    Having all AMD-kexts there except one is beneficial for 'proper' operation.

    To get some display acceleration back it will be necessary to force the machine to not boot into discrete graphics (dGPU) but directly into integrated graphics (iGPU). This will give you back your laptop – but you will lose some features: e.g. the ability to drive an external display. Thunderbolt data connections should work.

    The initial procedure:

    – To start from a clean slate: reset SMC and PRAM/NVRAM:

    shutdown, unplug everything except power, now hold


    release at the same time;

    – Now power on again and hold


    at the same time until you hear the startup chime two times.

    – Boot into Recovery by holding


    – Disable SIP:

    csrutil disable

    – disable dGPU on boot

    nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

    – enable verbose boot mode:

    nvram boot-args="-v"

    – reboot into single user-mode by holding


    on boot

    – mount root partition writeable

    /sbin/mount -uw /

    – make a kext-backup directory

    mkdir -p /System/Library/Extensions-off

    – only move ONE offending kext out of the way:

    mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/

    – let the system update its kextcache:

    touch /System/Library/Extensions/

    – wait for the kextcache process to finish


    Reboot normally:
    you will have an accelerated iGPU display.

    But the system doesn't know how to power-management the failed AMD-chip.
    For that you have to either manaully load the kext after boot by:

    sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext

    Automate this with the following LoginHook:

    sudo mkdir -p /Library/LoginHook
    sudo nano /Library/LoginHook/

    with the following content:

    kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
    exit 0

    then make it executable and active:

    sudo chmod a+x /Library/LoginHook/
    sudo defaults write LoginHook /Library/LoginHook/

    Preventive measures for future use

    There are two further caveats to know: This is reversible when the SMC/PRAM/NVRAM is reset. If that happens the GPU-power-pref nvram can/has to be set again to force the use of the iGPU from boot-time.

    Since this can happen quite easily (and is often erroneously recommended way too many times than it is actually useful), you should probably prepare for such a scenario and create a simple script to greatly speed up the process and also make entering the necessary variable much less error prone:

    sudo nano /

    – Enter the following content to this file:

    sudo nvram boot-args="-v"
    sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
    exit 0

    – Now make that executable:

    sudo chmod a+x /

    In the future, when the SMC/PRAM/NVRAM gets reset to default values it is now possible to boot into SingleUser with:


    – And after mounting your boot-volume read-write to execute just:

    sh /

    This setup has now one kext in a place Apple's installers do not expect. That is why in this guide SIP has not been reenabled. If an update that contains changes to the AMD drivers is about to take place it is advisable to move back the AMDRadeonX3000.kext to its default location before the update process. Otherwise the updater writes at least another kext of a different version to its default location or at worst you end up with an undefined state of partially non-matching drivers.

    After any system update the folder /System/Library/Extensions has to be checked for the offending kext. Its presence there will lead to e.g. a boot hang on Yosemite and Sierra, an overheating boot-loop in High Sierra.

    Further: this laptop is overheating, no matter what you do. The cooling system is inadequate and the huge number of failing AMD chips are just proof of that.

    To prolong the life of this now hacked machine it is advisable to abstain from really heavy lifting over prolonged stretches of time. Strictly follow the usual recommendations for laptops: use on hard surfaces, keep the fans and fins inside it clean. Using any fancontrol software with relatively aggressive settings should also help: like smcFanControl, MacsFanControl, or TGPro (the latter both commercial).

    This is fairly complete and what I do recommend to everyone asking me.
    Nevertheless. We're not done here, yet. Improvements are welcome. Share them!

Share This Page