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. nsgr, Aug 27, 2017
    Last edited: Aug 28, 2017

    nsgr macrumors 6502

    Joined:
    May 22, 2017
    #826
    There is an alternative reset SMC. I once solved the problem of MagSafe not charging the battery.

    The “normal” reset SMC do not work for me.

    If you can not solve the problem of high fan speed, maybe this is an alternative.


    1 - Turn off the Macbook Pro.

    2 - Disconnect the MagSafe.

    3 - Open the bottom of Macbook Pro 2011 (screws).

    4 - Disconnect the plug battery that is connected to the logic board (Photo).

    https://d3nevzfk7ii3be.cloudfront.net/igi/eTItfxSqYQIKnTf1.medium


    5 - Press the Power button for 30 seconds.

    The Macbook Pro 2011 will try to turn on but there is no power (Magsafe unplugged and battery connector unplugged).

    Any remaining charge from the logic board and the rest of the Macbook Pro will be discharge.


    6 - Reconnect the battery plug to the logic board.

    7 - Close the bottom of the Macbook Pro 2011 with the screws.

    8 - Connect the MagSafe in Macbook Pro 2011 and press the Power button to turn on the Macbook.


    Example:

    In my case I added press the Power button for 30 seconds. Old times of PC notebook.

    Some people disconnect the plug from the battery and wait for 2 minutes.


     
  2. saldin macrumors member

    Joined:
    Jul 30, 2012
    #827
    Hi,

    My 2011 MBP 15" failed this year and can't go to Apple for help anymore. I was looking for ways to disable the AMD GPU and found this thread just now (seriously).

    I have one question: do the NVRAM commands you just listed supersede the solution detailed in post #1?

    How could it be undone in case I get a AMD reflow/reball later on?

    Thank you very much!
     
  3. MikeyN, Aug 28, 2017
    Last edited: Aug 28, 2017

    MikeyN macrumors regular

    MikeyN

    Joined:
    Jul 26, 2017
    #828
    They are not superseding the historic post No. 1. They are just a different method to achieve effectively the same result. Going the NVRAM route is just much faster, easier and quite a bit less error prone.

    The hack will come off clean, that is: it is entirely, easily and quickly eliminated by doing NVRAM/PRAM/SMC reset. I redid it several times.

    Oh. And in case of reflowing/baking (possible, but not recommended: you should prefer a complete chip replacement instead) there is the added benefit that you probably do not have to intervene at all.
    See the method for resetting the NVRAM just posted by this great guy: https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-34#post-24938097
     
  4. Kjeld Flarup macrumors newbie

    Joined:
    Aug 21, 2017
    #829
    Thanks to all the good people writing on this thread.

    I followed the archlinux way and changed the EFI, and it worked until the next reboot, then all was forgotten.
    Then I tried to removed the kext files, but then I could not enter sleep mode.

    After running this nvram command, it seems that my problems are gone. Seems like the nvram command is performing a better job.

    Big question is, do we need the archlinux step at all, do we need to remove the SIP and the kext files?
    Is all that is needed to do, just to enter single user mode and run the above command?
     
  5. mikecwest macrumors 6502a

    mikecwest

    Joined:
    Jul 7, 2013
    #830

    Are you saying that, when my computer starts acting like a fool with the blue squiggles, I can go into single user mode and enter that command, to get kicked back to the integrated graphics mode?
     
  6. noname007 macrumors newbie

    Joined:
    Aug 28, 2017
    #831
    Hello.
    First of all, I want to thank for the solution provided here. It had worked from the first attempt for me and brought stable work back to my mbp17(late 2011).
    However, this solution has a little drawback, in my case at least. I've spend a lot of time, back when dGPU turned my mbp off every now and then, observing the temperature of the CPU and GPU ("CPU Die - Digital" and "GPU Die - Analog" in "iStat Menus"). When "Integrated only" was selected in gfxCardStatus the temperature of the GPU in idle was 15-25C and sometimes "iStat Menues" was showing "-" instead of a value. When "Discrete only" was selected the temperature of the GPU in idle was 35-45C and it seems the temperature of the CPU became higher as well. After applying the fix I see that I can't enable GPU but the temperature pattern now completely corresponds to the case when GPU was enabled, i.e. the GPU in idle is 35-45C and the CPU temperature in idle is higher on about 10C then it used to be for "Integrated only" mode. I can't say for sure if it affects a battery time as well, as I rarely use it without an ac adapter.
    So, the question is am I the only affected or it's a thing I must put up with? Is there a chance that with some other parameter put in "gpu-power-pref-..." the dGPU can be disabled completely?
     
  7. Kjeld Flarup macrumors newbie

    Joined:
    Aug 21, 2017
    #832
    I have an assumption, but I cannot verify it on my own MBP, because I messed around with a lot of solutions already.
     
  8. mikecwest macrumors 6502a

    mikecwest

    Joined:
    Jul 7, 2013
    #833

    I only recently encountered this issue again (it happened two other times, one time I did a Depot repair, the other it was fixed under the recall...

    Friday, I got my new failure. I Tried the archlinux thing, and it seems to work, but so far at least once a day, I have to re-do it. It would be nice if that single line code in single user mode works. (Just boot into SU mode, and press UP arrow to select previous commands... I'll try it next time it fails.
     
  9. MikeyN, Aug 28, 2017
    Last edited: Aug 28, 2017

    MikeyN macrumors regular

    MikeyN

    Joined:
    Jul 26, 2017
    #834
    The Linux step is not required – anymore. It is an alternative and the original way. Since it is error prone users report limited success even though it is perfectly viable and works like a charm. One thing of note is that the post No1 in this thread has sadly not been updated in a while and is therefore incomplete regarding several findings to improve the situation a bit further. One of these findings is that the NVRAM method also works and produces the results in an easier way, therefore – in that sense – it might be said it is performing a better job.


    These are not that bad temps after all. You did move X3000 kext and only that and manually loaded it afterwards, right?

    Thankfully, there's a script for that: #572
    But seriously.
    Stop worrying about linux.
    Prepare that script as described. Next time your machine fails to do your bidding: perform SMC reset, perform NVRAM reset. then boot single user, mount root as read-write as described on screen and then just run the script.
    Presto, fix applied, and it should stick.
     
  10. noname007 macrumors newbie

    Joined:
    Aug 28, 2017
    #835
    I moved all AMD kexts. Didn't understand what manual loading means, I just turned on mac after kext moving and it worked without issues ever since.
    Temps are not bad, but I have an impression that the dGPU is still working and these older macs tend to heat up to 100C in some cases. Complete disabling of the dGPU would be great.
     
  11. MikeyN macrumors regular

    MikeyN

    Joined:
    Jul 26, 2017
    #836
    And that's the problem.
    Move all the kexts back, except AMDRadeonX3000.kext.
    touch /System/Library/Extensions
    wait 2 minutes
    reboot
    everything still working as before?

    Watch the temps!

    sudo kextload /pathtoyour/AMDRadeonX3000.kext


    That's manual load.

    Watch the temps!

    If you like what you see, then like #593 for inspiration and look at Update2 in #599.
     
  12. mac_4eva macrumors member

    mac_4eva

    Joined:
    Jun 15, 2016
    Location:
    Atlanta, GA, USA
    #837
    Instead of using a LoginHook, you may also opt for a LaunchAgent, that runs on login. A neat solution nonetheless.
    --- Post Merged, Aug 28, 2017 ---
    Thanks for that, will look into it an update.
     
  13. saldin macrumors member

    Joined:
    Jul 30, 2012
    #838
    Thank you very much, MikeyN!!!! You're a hero to every MBP 2011 owner!!! It now boots reliably and consistently!!!

    BUT... I'm noticing it doesn't shutdown cleanly now. Could you please help me figure out what's wrong?

    Since I changed the boot-args to verbose as advised, it shows this and gets stuck:

    Process mds_stores [214] disabling system-wide I/O Throttling
    Process mds_stores [214] disabling system-wide CPU Throttling
    in6_unlink_ifa: IPv6 address 0x0000000000000000 has no prefix
    AFP_VFS afpfs_unmount: /Volumes/AirDisk, flags 0, pid 528
    ASP_TCP Disconnect: triggering reconnect by bumping reconnTrigger from curr value 0 on so 0x0000000000000000

    ASP_TCP Detach: Reply queue not empty?

    Mon Aug 28 22:00:00 2017 MacBookBroke.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Notice>: Userspace teardown took: 8006 ms
     
  14. Kjeld Flarup macrumors newbie

    Joined:
    Aug 21, 2017
    #839
    I guess that this finding is written in some of the 300 post I didn't read. I hope for others that post #1 is updated. Or perhaps a new thread is started.
     
  15. mikecwest macrumors 6502a

    mikecwest

    Joined:
    Jul 7, 2013
    #840
    my problem came back again, I did the NVRAM thing, and it did not do anything for me...
     
  16. MikeyN macrumors regular

    MikeyN

    Joined:
    Jul 26, 2017
    #841
    Maybe. On Yosemite I had not the same but similar issues. It would never hang completely (my guess, I grew quite impatient with it at times) but it took sometimes an extraordinary amount of time to let it run its things and eventually shutdown cleanly.
    So I very reluctantly gave up on Yosi. Sierra didn't give me issues.
    If you are on 10.11 or 10.12 then you should look more into what the message above tells you. Looks more like a network issue than something caused by the hack.
    Try to unmount all networks drives and close all network connections before issuing the shutdown command.
    Some more info on this would be helpful.
    Exact symptoms? Did you reset NVRAM/SMC (yes, again) before (re-)applying NVRAM-hack?
     
  17. SergioF macrumors newbie

    Joined:
    Aug 25, 2017
    Location:
    Algoz, Portugal
    #842
    I have now tried this hack with 2 different MBP 8,3 and both times the hack worked.

    Both MBP would not boot and showed vertical coloured stripes against the grey screen. These are the steps I used:
    1. Created the Arch Linux LiveUSB as per instructions on first page. This enabled me to see that the gpu-power-prefs variable was present in /sys/firmware/efi/efivars. (optional step)
    2. Removed the gpu-power-prefs variable and also all other gpu vars from /sys/firmware/efi/efivars by doing a
    SMC/PRAM/NVRAM reset:
    hold <leftShift><Ctrl><Opt><Power> for two seconds, release at the same time.
    And then with machine still powered down.
    Hold <Cmd><Opt><p><r> while powering on and wait until you hear the startup chime two times.
    NVRAM is now at factory settings.
    3. Booted to single user mode <Cmd><s> on boot. Did a fsck -fy first and then as per MikeyN instructions issued the following commands:
    nvram boot-args="-v"
    nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
    reboot

    4. I then removed the AMDRadeonX3000.kext from the Mac OS installation by booting from an external HD with Sierra installation that already had no AMDRadeonX3000.kext. Load external HD with Sierra (minus AMDRadeonX3000.kext) and then search for the AMDRadeonX3000.kext within the internal disk /System/Library/Extensions and delete the offending kext. Without removing the AMDRadeonX3000.kext I found that on the first MBP (Sierra) the hack worked only on first boot the problem re-occurred and I had to do the hack again and on the 2nd MBP (Yosemite) it didn't boot at all.

    Thanks to MikeyN for his help and instructions I have now managed to get two 17" MBP back in working condition.
     
  18. saldin, Aug 29, 2017
    Last edited: Aug 29, 2017

    saldin macrumors member

    Joined:
    Jul 30, 2012
    #843
    I'm running Capi 10.11.6, but the latest security update is still pending installation. The computer has maxed-out memory (16 GB PC3-12800 Corsair Vengeance) and upgraded storage (480 GB OWC Mercury Electra 6G).

    When it was working fine, or in the late stages of its degenerative disease when I got it to boot correctly after much effort, it would shutdown very quickly. Now it gets stuck shutting down or rebooting. I tried to see if it would get stuck after a reboot command as well, and it didn't show the text on that occasion and then ever again. I admit I was too impatient and turned it off forcibly without giving it enough time. I also admit I didn't test sleep/hibernation or wake-up to see if it worked after applying the hack. I will wait longer (and time it) and test sleep/wakeup and report back.

    I applied the hack in 3 reboot cycles: one for disabling SIP, another for moving the kext and modifying the nvram, and the last one for reenabling SIP. I didn't try to erase it and reapply after it was working, but I will try that and report back.

    I'm also willing to upgrade to Sierra, I just need some pointers:
    • I read it's suggested to put back the AMDRadeonX3000.kext back in the Extensions folder in order to successfully run updates and upgrades, but wouldn't that break the hack and prevent it from booting?
    • After the upgrade finishes and reboots, I expect the installer to have overwritten the hack. Should I immediately access single-user mode and remove the X3000.kext and reapply the nvram hack before it tries to boot for the first time?
    I thank you again, from the bottom of my heart, for all your help and dedication to us, MBP 2011 owners.
     
  19. nonlen macrumors newbie

    Joined:
    Mar 29, 2014
    #844
    Hi, 2 questions...
    3. What is "Did a fsck -fy first" ?
    4. After the hack, is it possible to remove the AMDRadeonX3000.kext from the internal drive without using / booting from an external HD?

    Thanks
     
  20. MikeyN, Aug 29, 2017
    Last edited: Aug 29, 2017

    MikeyN macrumors regular

    MikeyN

    Joined:
    Jul 26, 2017
    #845
    Alas, for ElCap I do not have personal experience to offer. But I think I do I not understand correctly "and it didn't show the text on that occasion and then ever again.": that the problem is gone?

    If you are doing the SecurityUpdate for ElCap now or soon:

    Stop and Read!


    "The hack" is the NVRAM-variable. The hack will not be overwritten. These installers do not trigger an NVRAM reset.
    Even the frequent EFI-Updates that come with High Sierra betas do not overwrite the hack.

    And just in case the hack does get removed/overwritten somehow; actually, and anyhow: Prepare the script from #572. If you loose the hack (through an NVRAM-reset) and have this script prepared, then your downtime is reduced to ~20 sec.

    But: These updates install newer AMD driver kexts. A 'full' set. 'Full' is in air quotes because:
    We have discovered that these SecurityUpdates for Yosemite, ElCap and also the .6-Update for Sierra contain updates/upgrades to the AMD driver kexts. Sadly these are incomplete in very subtle and minor ways. But on Yosi and ElCap at least they will bring you trouble if applied blindly.

    For this reason it is at least advisable to get your latest AMDRadeonX3000.kext back into /System/Library/Extensions before the update/upgrade procedure.

    This ensures that you have only one X3000 kext and that it will be complete and up-to-date. It then has just to be moved again.

    It is best to not use the AppStore download. Use the standalone installer: https://support.apple.com/kb/DL1932?locale=en_US
    Apply that install only after you have disabled SIP! (Update also will work with SIP enabled. Saves you headaches in the next step.)

    After the update is complete, your system will have problems. That is to be expected: The kext is back in place. You have to deal with one botched boot. Since you have disabled SIP: force a reset, boot SingleUser move the kext to your preferred place, type touch /System/Library/Extensions and wait ~2 minutes. Then reboot, back into the game.

    #####

    If you decide to upgrade to Sierra:


    This too will very likely not change the NVRAM hack.
    Opt for a clean install. No upgrade, no migration assistant. This might sound painful for some.
    (Try diskmakerx.com to create an install medium).

    But after the installer is finished, it then tries to boot into a system with the crucial kext again in its default place.
    From there on you have two options. First and maybe not so good: boot into SafeMode, finish AppleSetup with unaccelerated graphics.
    Or perhaps, better to start directly with what would have to come next: you can then force reboot, boot into RecoveryMode, disable SIP, reboot SingleUser, move the kext to your preferred location. Do not forget to type touch /System/Library/Extensions and wait ~2 minutes.
    Next reboot should be fine.
     
  21. mikecwest macrumors 6502a

    mikecwest

    Joined:
    Jul 7, 2013
    #846
    Ok, I reset the SMC and zapped the PRAM, it came out blue squiggly after that. I ran the terminal commands, and it came out clear with the Intel video.

    That is a lot easier than the Linux method.

    I have made a file, to make things easier, you are free to use it if you wish...

    It does the NVRAM hack, sets in in verbose mode (thats what the -v boot-args flag does.), and also sets kext-dev-mode to enabled. (just in case you have CAT installed).... You can edit out what you don't want or need. I don't believe you can disable SIP from single user mode, so you will still have to redo that everytime you SMC/PRAM reset.

    To use it, just unzip the contents to the root of you boot drive. Start in single user mode and type "bash roxy" (without the quotes and press enter.....it will type out the long tedious commands and reboot automatically.

    (Roxy is that little kitty wearing the Rudolph costume under my name, although she is no longer little)
     

    Attached Files:

    • roxy.zip
      File size:
      351 bytes
      Views:
      243
  22. saldin macrumors member

    Joined:
    Jul 30, 2012
    #847
    I reset the SMC and PRAM again and reapplied the hack. Tested rebooting and shutting down the system three times and timed them, but I stopped each attempt at 5 minutes and forcibly powered off the system. I conclude it doesn't shutdown or reboot right anymore.

    I also tested closing the lid and waiting until the system started sleeping (when the light does the breathing pattern) and then opened the lid and waited two minutes. Attempted three times and the keyboard backlight powers on but the screen stays off. I can use the backlight control keys and dim them at will, though. I conclude sleep/wakeup doesn't work right anymore.

    Still, I'll take inability to shutdown/reboot and sleep/wakeup to a system that doesn't even boot.

    I wholeheartedly thank you for the care you put in writing detailed instructions for me to upgrade Capi with the security update and to install Sierra. It's hard for me to install Sierra clean, but I'll definitely do the security patch and retry the testing. If push comes to shove, I'll backup everything and install Sierra clean.

    Do you know if the computer can keep operating with the hack and the HD3000 indefinitely, or if continued degeneration will eventually make it reach true death?

    Thank you very much for all your amazing help!!!!!!
     
  23. SergioF macrumors newbie

    Joined:
    Aug 25, 2017
    Location:
    Algoz, Portugal
    #849
    fsck -fy checks the integrity of the files system. I did in just in case especially if the system had been shutting down abruptly because of the graphics problem fsck -fy will correct any errors on the OS.

    Yes you can use a normal user with admin privileges to remove kext from an external OS installation. In my case I did it the other way, booted the system with an external drive <opt> on boot and then choose to boot from the external drive, already without the kext, and then use the external system to find and remove the kext from the internal drive. Hope that makes sense to you.

    I would use the same method for upgrading in the future, if you have access to an external drive with an installation of OS. Boot from the external OS and then use it to upgrade the internal disk and then use it again to remove the kext. This way you don't have reapply the hack.
     
  24. afide, Aug 30, 2017
    Last edited: Aug 30, 2017

    afide macrumors newbie

    afide

    Joined:
    Aug 25, 2017
    #850
    Ok so I followed the guide on page one and everything seems to be working fine, should I do anything else? Thanks everyone
     

Share This Page