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

[madhatmac]

Unloading the kext will also crash Sierra here. That might be a caveat for your plans on upgrading. Keep your current install on a bootable backup.

Sorry, I was sure I manually unloaded the kext and it worked but I tried it again and El Capitan crashed. Also, in addition to the sleep issue with the kext loaded, the computer will hang when I try to restart or shut down. I end up having to force shut it down.

The AMD kexts should be all back now to load at boot except the X3000.
Remember: This needs to be put back before system updates.

Does this mean I have to move the AMDRadeonX3000.kext back to /System/Library/Extensions/ before I update to Sierra?

And doesn't Sierra need to boot to apply its updates? ie. won't it hang if the kext is reloaded by the OS update?

 

[MikeyN]

Sorry, I was sure I manually unloaded the kext and it worked but I tried it again and El Capitan crashed. Also, in addition to the sleep issue with the kext loaded, the computer will hang when I try to restart or shut down. I end up having to force shut it down.

Does this mean I have to move the AMDRadeonX3000.kext back to /System/Library/Extensions/ before I update to Sierra?

And doesn't Sierra need to boot to apply its updates? ie. won't it hang if the kext is reloaded by the OS update?

Having the kext loaded lead to a severe delay for reboot and shutdown under Yosi here also. But it did not really hang. The time needed differed but eventually it would shut down most of the time. Further, rebooting via CLI would cut this short quite effectively:

sudo reboot # reboot
sudo shutdown -r now # reboot
sudo shutdown -h now # shutdown


###

What I meant was to put the kext back if you are updating. That is applying a security update for Yosi (the last one 2017-003 modified the kext: it put a X3000-kext into the System-folder. It has the same version number but a different file size. I did not examine in detail what exactly differs there. Looks like it was an amending delta update, not a full kext like in combo updates.)

The upgrade to Sierra works with just the nvram-fix in place since kext3000 is not part of BaseSystem loaded during install process. But the first boot after install is completed will hang.
I then first completed the setup in safe-mode but I guess it would have been the better solution to immediately start the SIP-dance and properly move the kext then.

Alternatively one could extract a full install to a different disk, then clone that to your main drive. Bypassing most of Apple's hogging-mode installer.

What happens with Sierra when there are updates available for it now I haven't experienced yet. But if the update contains something with AMDRadeonX3000.kext then we need to act.

 

[GDBO]

Is there a working fix for Bootcamp as well?

 

[MikeyN]

Is there a working fix for Bootcamp as well?

Apparently no-one succeeded there so far.
I do not use BootCamp and so I haven't looked into the drivers there.
But have you tried to install
http://support.amd.com/de-de/download/desktop/bootcamp ?

 

[Mike--W]

FIX WITH OS X SIERRA AND NO RECOVERY PARTITION

Had a MBP which would not boot normally - vertical yellow and white stripes, apple logo and progress bar half-way, then blank white screen. The vertical bars were blue and white in single-user mode. Decided to try the fix in this thread, but with OS X Sierra its not so easy.

First off - thanks a million for this.

I tried to follow the steps, but was a bit shaky over the edits using the Arch Linux boot disk - I am still not sure if you have put the necessary quotes around printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 and whether this file should have the file extension .efi_gpu but I managed to create the file.

In single user mode I tried to move the AMD kexts, but the Sierra OS X SIP prevented me. I did not have a recovery partition either, as I had cloned this disk from another. I therefore had to use Recovery Partition Creator 4.0.4 to create one. This app protested that I had a Core Storage volume - that I didn't think I had - and threw an error. It neverless created the recovery partition, from which I could use the terminal to disable SIP with " csrutil disable ", and I also moved the AMD Kexts to a new root folder and cleared the cache as suggested.

I had a graphics glitch on first reboot, but on second reboot the AMD drivers were not present, and after 24 hours the MacBook is still working. I'm keeping my fingers crossed.

Thanks again for sparing me the need to get the chip replaced in China. This Youtube film might is interesting especially if what he says is true:

Mike

 

[MikeyN]

Disable hardware acceleration for Chrome and Firefox.

1 - Chrome

Menu Chrome (version 60.0.3112.90) or (Command ,) -> Preferences -> Advanced -> System -> Use hardware acceleration when available -> selector gray color (disable) -> restart Chrome.


2 - Firefox

Menu Firefox (version 54.0.1) or (Command ,) -> Preferences -> Advanced -> Use hardware acceleration when available -> unchecked -> restart Firefox

Safari is not using hardware acceleration?
I do not believe that to be true. Also I notice that the biggest spikes in temp for e.g. Chrome or Firefox are not when running them but when they initialise. Disabling HW-acceleration is a less efficient solution over all.
Seems to me that disabling TurboBoost is a better approach to keep the system cool.
TurboBoost is Intel intentionally raising the allowed temps to overclock the chips for a short time. Most of us here do not want this anymore. Its also quite useless imho since it goes right back into throttling because the temps were raised to a level too high. Gaining nothing but worries and whine in the meantime.

Look here for someone on Windows noticing high temps when launching Firefox:
http://www.geeks3d.com/20170213/how-to-disable-intel-turbo-boost-technology-on-a-notebook/

Nagware:
https://github.com/rugarciap/Turbo-Boost-Switcher

Old unsigned kext for that:
https://github.com/nanoant/DisableTurboBoost.kext

Makes me wonder now if there is not an EFI/nvram variable for that?

 

[mac_4eva]

Boot verbose is mandatory for all Macbooks with this Died GPU problem. Avoid the Apple logo with progress bar.

Do not modify the AGPM.

Are you having this error with an external gpu connected to Macbook Pro? Or is this error only with the Intel and Nvidia GPUs?

My starting point for the IOScreenLockState IOConsoleUsers was that after the sudo nvram GUID: gpu-power-prefs=%01%00%00%00, I realized that the Recovery Mode Graphical Interface worked correctly.

So I ran the ioreg command and saw the AMD kexts loaded.

For the Nvidia video card there must be something more because it has something with NVArch and also DeviceID.

Recovery Mode:

ioreg | grep -i nvdia

ioreg | grep -i nvda

ioreg | grep -i GK107M

ioreg | grep -i 0fe9


You have to compare the Recovery Mode kexts and the kexts of your Mac OS installed on the hard disk.

Recovery Mode -> OS Base System -> /System/Library/Extensions

Mac OS installed hard disk -> /System/Library/Extensions

Recovery mode has fewer Nvidia kexts. If the graphic interface works, then you have to focus on these kexts.

Normal boot:

grep -Ril nvda /System/Library/Extensions/

/System/Library/Extensions//AppleVADriver.bundle/Contents/MacOS/AVA_HD_VP3.dylib


Open the file AVA_HD_VP3.dylib with TextEdit and you will see several references to NVDA and Nvidia.

I do not know if this file might be the problem.


Dylib = dynamic library

Not connecting the eGPU. Standard setup only.

Thanks for elaborating. I shall look into this more closely. Not sure what I would do with that dylib. As per your suggestion, I'll look for kext discrepancies in recovery vs. install for High Sierra. Also, quick update that with my current selection of kext moves, beta 6 also does not boot.
[doublepost=1502808998][/doublepost]Additionally, I have a quick question regarding disabling the dGPU in general. The NVRAM variable that @nsgr pointed out uses only the iGPU for one boot - and not moving relevant dGPU kexts means the dGPU stays cool. So why not make a LaunchDaemon + Script that keeps updating the variable instead of moving kexts (eliminates need to disable SIP as well)?

 

[alediaz84]

Hello, this fix works great! Fixed two MacbookPro 2011 so far.
Did anyone tried this on a MacBook Pro 4,1 (15-inch Early 2008)? Any idea if this will work?

 

[MikeyN]

Additionally, I have a quick question regarding disabling the dGPU in general. The NVRAM variable that @nsgr pointed out uses only the iGPU for one boot - and not moving relevant dGPU kexts means the dGPU stays cool. So why not make a LaunchDaemon + Script that keeps updating the variable instead of moving kexts (eliminates need to disable SIP as well)?

For the AMD failure of this thread we need to load all relevant kexts but defer the loading of one kext that therefore had to be moved once out of the extensions folder of the system. A script is not needed for moving the one kext but is useful for loading it after boot.

The nvram variable is supposed to stay across reboots. And it usually does for most of the participants in this thread?
The interesting path to success is finding out how this somehow seems to fail with your (and a couple others) setup.
Finding the culprit may lead to fixing it. If we cannot really fix it this might still be useful: Finding out why and exactly when this setting gets erased from the nvram also limits the needed scope for such a work around that you proposed. It would be overkill to have launchd write that nvram variable every second.
But as a workaround to get this setup you need off the ground this might work, if the variable is really overwritten before launchd stops loading and executing new .plists.

 

[mac_4eva]

For the AMD failure of this thread we need to load all relevant kexts but defer the loading of one kext that therefore had to be moved once out of the extensions folder of the system. A script is not needed for moving the one kext but is useful for loading it after boot.

The nvram variable is supposed to stay across reboots. And it usually does for most of the participants in this thread?
The interesting path to success is finding out how this somehow seems to fail with your (and a couple others) setup.
Finding the culprit may lead to fixing it. If we cannot really fix it this might still be useful: Finding out why and exactly when this setting gets erased from the nvram also limits the needed scope for such a work around that you proposed. It would be overkill to have launchd write that nvram variable every second.
But as a workaround to get this setup you need off the ground this might work, if the variable is really overwritten before launchd stops loading and executing new .plists.

From my understanding, the NVRAM value does not hold when drivers/kexts of the discrete GPU that are present and loaded. Therefore removing the offending drivers ensures the value holds. Now, if we were to never remove the kexts, then the value would not hold (this is how oxbb's gpu-switch works I believe - since it does not move kexts) and you would get only one boot with iGPU-only usage. Please correct me if I'm wrong.

Given this, which is what I believe to be correct, writing a script that only executes once (there is no need to continuously update the value as you might have inferred) on boot or on shutdown to update the NVRAM, should, in my opinion, solve the needs of the members of the thread?

 

[JasonB824]

I had done FGuarini's fix (pg. 5 of this thread) a couple months back and my system was working fine on 10.12.5. My system updated itself to 10.12.6 and the error came back. Naturally I tried repeating the same steps...except this time I can only operate in safe mode. Without safe mode it does a boot loop. What is it about the 10.12.6 update that ruined this fix? Anyone know what edits I need to make?

 

[rlebleu]

I had done FGuarini's fix (pg. 5 of this thread) a couple months back and my system was working fine on 10.12.5. My system updated itself to 10.12.6 and the error came back. Naturally I tried repeating the same steps...except this time I can only operate in safe mode. Without safe mode it does a boot loop. What is it about the 10.12.6 update that ruined this fix? Anyone know what edits I need to make?

I used the process described in post #528 after my Macbook Pro updated to 10.12.6 and it worked fine. Key points: All AMD Kexts are refreshed with this update. They can remain where they are in System/library/extensions with the exception of AMDRadeonX3000.kext which must be moved to another folder (/AMD_Kexts or whatever) to avoid loading at boot time. After booting, it should be loaded via Terminal to keep the temperatures down. That is described in the post above.

 

[JasonB824]

I did that, but after doing the other first. Perhaps, I need to move all of them back for it to work now? Any easy way to do that. I tried doing a PRAM and SMC reset and then doing post 528, but still got stuck in boot loop on regular boot.

 

[rlebleu]

I did that, but after doing the other first. Perhaps, I need to move all of them back for it to work now? Any easy way to do that. I tried doing a PRAM and SMC reset and then doing post 528, but still got stuck in boot loop on regular boot.

Did you boot into the Recovery partition? Hold Cmd-R-S when booting? It uses a Recovery process to boot from a different partition on the hard drive, and does not use the updated 10.12.6 system. I don't don't know where you moved the AMD Kexts, so I can't give you detailed instructions. But all you have to do is move them back. Failing that, reinstall macOS 10.12.6. Thats should do it.

 

[MikeyN]

From my understanding, the NVRAM value does not hold when drivers/kexts of the discrete GPU that are present and loaded. Therefore removing the offending drivers ensures the value holds. Now, if we were to never remove the kexts, then the value would not hold (this is how oxbb's gpu-switch works I believe - since it does not move kexts) and you would get only one boot with iGPU-only usage. Please correct me if I'm wrong.

Given this, which is what I believe to be correct, writing a script that only executes once (there is no need to continuously update the value as you might have inferred) on boot or on shutdown to update the NVRAM, should, in my opinion, solve the needs of the members of the thread?

The NVRAM variable here holds whether none, all except one, or all kexts are present. The crucial NVRAM value should ensure that iGPU is always used at boot time. Across reboots. Set only once and holding until the next NVRAM reset or that value is rewritten. That is now for many reboots and a complete new system installation.
If that is not the case with your setup there is likely something wrong/different with the process, I believe.
Since this behavior was reported not only from you with eGPU special needs and AMD/NVidia mixing but from users in this thread that initially only had problems with 2011 AMD this is especially interesting.
For me that indicates that it is not so much the hardware difference at play here.
What is the problem here: somehow somewhat shaky NVRAM? Seems very strange. Something directly rewriting the value? Something triggering a rewrite or reset? That is much more likely, imho. Of course that might all be baseless speculation if indeed NVidia drivers trigger NVRAM values to change.
If that is the case then I wonder if it would suffice to wait that NVidia drivers are loaded and then write to NVRAM. I doubt that the drivers constantly cause writes to NVRAM.

In first going the linux route I reasoned that not (re-)setting immutable flag to this value would make it less robust. Finding out that the nvram command would suffice made me not pursue this line of reasoning any further.
But then I found that the efivars directory is much larger than what nvram -p would show you. Therefore I think that issuing nvram -c might not be enough to really get factory defaults. Just booting OS X fills up some efivars after an SMC-reset, some of them related to GPU.

You wrote "present and loaded". Would it be a workable solution for your needs now to have the kext 'present'(in a non standard location) but not autoloaded at boot but later?

 

[JasonB824]

I did that, but after doing the other first. Perhaps, I need to move all of them back for it to work now? Any easy way to do that. I tried doing a PRAM and SMC reset and then doing post 528, but still got stuck in boot loop on regular boot.

All my commands keep returning read only system in the Terminal as well and I've tried mount -rw command as well.

 

[madhatmac]

What I meant was to put the kext back if you are updating. That is applying a security update for Yosi (the last one 2017-003 modified the kext: it put a X3000-kext into the System-folder. It has the same version number but a different file size. I did not examine in detail what exactly differs there. Looks like it was an amending delta update, not a full kext like in combo updates.)

The upgrade to Sierra works with just the nvram-fix in place since kext3000 is not part of BaseSystem loaded during install process. But the first boot after install is completed will hang.
I then first completed the setup in safe-mode but I guess it would have been the better solution to immediately start the SIP-dance and properly move the kext then.

I updated to Sierra 10.12.5 and everything is good now. Sleep is working and the temps are good when the AMDRadeonX3000.kext is manually loaded. Thanks for your help.

Sorry, just to clarify, do you mean the AMDRadeonX3000.kext that is currently in /AMD_Kexts needs to be put back into System/Library/Extensions before updating to say, for example, 10.12.6? Or can it just remain loaded in /AMD_Kexts and when I update via the App Store it will create a new AMDRadeonX3000.kext that I then have to move - maybe create a new folder called /AMD_Kexts_10_12_6 so it doesn't get confused with the old one?

And, if you do mean AMDRadeonX3000.kext has to be moved back to to System/Library/Extensions before an update, how would one do that as you need to be booted into normal Mac OS to apply an update from the App Store?

 

[Audit13]

Could it be that Chrome is causing a problem because support for HD3000 is being dropped?

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/I6dL_9IAwiE

 

[MikeyN]

Could it be that Chrome is causing a problem because support for HD3000 is being dropped?

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/I6dL_9IAwiE

According to that thread HD3000 support is not dropped completely but blacklisted for offloading stuff to that GPU. That means the advice in #717 ("when available") is not effective for Chrome since it already does not use GPU features on HD3000. I forced these features on by overriding the blacklist through flags. With Chrome 61.0.3163.39 it then uses the iGPU for up to 2 seconds fine and then crashes ("Rats! WebGL hit a snag").
In both cases temps of the system stayed manageable (GPU-diode now at 1°C). Forcing these settings in Vivaldi does not crash the browser process as WebGL just stays disabled.
Safari Version 11.0 (12604.1.35) seems to blacklist too:
http://webglreport.com
Firefox 56.0b2 seems to work OK without blacklisting HD3000.
None of these experiments with browsers showed indecent use of temperature allowance with TurboBoost disabled.

Sorry, just to clarify, do you mean the AMDRadeonX3000.kext that is currently in /AMD_Kexts needs to be put back into System/Library/Extensions before updating to say, for example, 10.12.6? Or can it just remain loaded in /AMD_Kexts and when I update via the App Store it will create a new AMDRadeonX3000.kext that I then have to move - maybe create a new folder called /AMD_Kexts_10_12_6 so it doesn't get confused with the old one?

And, if you do mean AMDRadeonX3000.kext has to be moved back to to System/Library/Extensions before an update, how would one do that as you need to be booted into normal Mac OS to apply an update from the App Store?

AFAIK the .6 update for Sierra als brings with it new AMD kexts. I do not know if that is available as just a (concerning X3000 big) delta update like the sec-update for Yosemite. Anyway, there will be some kind of a new X3000.kext installed. If it does not get wholly replaced but updated then the old kext should be in place. (If you really want to keep around the old kext rely on backups or extract it from the .5-combo update.)

As a recently forced convert from Yosemite, like me, one could just run the system with SIP disabled all the time. Yosemite did not have it at all. At least SIP should be disabled prior to applying the update: then mv kext, then update, then mv kext, then re-enable SIP (finding the last step a bit somewhat optional).

 

[madhatmac]

As a recently forced convert from Yosemite, like me, one could just run the system with SIP disabled all the time. Yosemite did not have it at all. At least SIP should be disabled prior to applying the update: then mv kext, then update, then mv kext, then re-enable SIP (finding the last step a bit somewhat optional).

OK, thanks. Obviously SIP has to be disabled in recovery mode (Cmd+R). What mode are you in when you mv kext? Can it be done while booted into normal Mac OS with sudo mv kext? Previously I only moved it when I was in single user mode (Cmd+S) but in this instance I need to download and install an update so I need to be booted normally to Mac OS I imagine (unless there's a way of installing dmgs with a command line in single user mode...).

 

[MikeyN]

OK, thanks. Obviously SIP has to be disabled in recovery mode (Cmd+R). What mode are you in when you mv kext? Can it be done while booted into normal Mac OS with sudo mv kext? Previously I only moved it when I was in single user mode (Cmd+S) but in this instance I need to download and install an update so I need to be booted normally to Mac OS I imagine (unless there's a way of installing dmgs with a command line in single user mode...).

To move this kext you have to be in SIP disabled mode. To apply an update you can be in SIP disabled mode.
SingleUser serves two functions derived from one feature: avoiding the GUI, 1. so you can boot at all with kext in place that is not loaded in this way, 2. so you can manipulate quickly the root file system. SingleUser boots way quicker then a half disabled GUI (safe-mode or recovery)

-->

Before an update, with SIP disabled, you can move back the kext while still booted normally.
After the update you might want to boot into single user to move the now updated/rewritten kext again from its default location. I wrote "might want" because with SIP disabled you could also chose safe-mode, waste a ton of time and move the kext in now slow as hell Terminal.app.

Most important point being:
Just to save time and trouble: Watch out for OS updates that contain AMD driver updates. Disable automatic update installation but check for update availability. Apply these updates after making sure that SIP is currently disabled. Failure to do so is easily recoverable, but wastes much much time.

As a recent convert to Sierra from Yosemite, especially on old hardware, you might also want to check out one of these suggestions to keep things cool:
https://forums.macrumors.com/thread...life-running-cool-and-general-sanity.2062117/

 

[JasonB824]

I tried reinstalling 10.12.6 then did the nvram command, followed by moving the AMD3000 kext. I still can only get into safe mode. I still hang on the lockscreen error on a normal boot. (I have checked for typos on the uuid's many times) I never did a SIP disable command anywhere (csrutil). However when after moving it, I do not see the 3000 kext in the Extensions folder anymore. I just followed the instructions from Post 528. After the first install I followed fguarini's instructions, which had worked for 2 months before the 10.12.6 update. I'm at a complete loss now and am looking at a new laptop...all because of this update.

 

[alembic]

@JasonB824, did you perform a clean install of 10.12.6? and the lockscreen error is just a black screen? do you have verbose startup enabled to see where the system is hanging?

 

[JasonB824]

FIX WITH OS X SIERRA AND NO RECOVERY PARTITION

Had a MBP which would not boot normally - vertical yellow and white stripes, apple logo and progress bar half-way, then blank white screen. The vertical bars were blue and white in single-user mode. Decided to try the fix in this thread, but with OS X Sierra its not so easy.

First off - thanks a million for this.

I tried to follow the steps, but was a bit shaky over the edits using the Arch Linux boot disk - I am still not sure if you have put the necessary quotes around printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 and whether this file should have the file extension .efi_gpu but I managed to create the file.

In single user mode I tried to move the AMD kexts, but the Sierra OS X SIP prevented me. I did not have a recovery partition either, as I had cloned this disk from another. I therefore had to use Recovery Partition Creator 4.0.4 to create one. This app protested that I had a Core Storage volume - that I didn't think I had - and threw an error. It neverless created the recovery partition, from which I could use the terminal to disable SIP with " csrutil disable ", and I also moved the AMD Kexts to a new root folder and cleared the cache as suggested.

I had a graphics glitch on first reboot, but on second reboot the AMD drivers were not present, and after 24 hours the MacBook is still working. I'm keeping my fingers crossed.

Thanks again for sparing me the need to get the chip replaced in China. This Youtube film might is interesting especially if what he says is true:

Mike

I have the same scenario as you. Can you let me know what commands you entered in terminal. I am wondering if I missed something (though oddly enough when I did this two months ago it worked fine with 10.12.5).

 

[MikeyN]

I tried reinstalling 10.12.6 then did the nvram command, followed by moving the AMD3000 kext. I still can only get into safe mode. I still hang on the lockscreen error on a normal boot. (I have checked for typos on the uuid's many times) I never did a SIP disable command anywhere (csrutil). However when after moving it, I do not see the 3000 kext in the Extensions folder anymore. I just followed the instructions from Post 528. After the first install I followed fguarini's instructions, which had worked for 2 months before the 10.12.6 update. I'm at a complete loss now and am looking at a new laptop...all because of this update.

In which "Extensions folder" are you looking?
If the the iGPU-NVRAM variable is set to correct values and AMDRadeonX3000.kext is not in /System/Library/Extensions then you should be able to boot into the full OS.

Please re-check in your safe-boot Terminal.
Type:

$ sudo nvram boot-args="-v"
# to enable verbose boot

$ /usr/bin/find /System/Library/Ext* -iname AMDRadeonX3*
# to find the troublemake kext

If that doesn't turn up anything, take a bit of time and wait for the following command to finish:
$ /usr/bin/find / -iname AMDRadeonX3000.kext

Memorize the output of the above command for the location as /path/to/your/kext.
The hang on boot is likely because the X3000 kext is present in a folder where it is auto-loaded at boot.

--> If SIP is currently enabled, and let's just assume it is:
Boot into SingleUserRecovery: holding <Cmd>+<r>+<s> on system start.
Type:
$ csrutil disable
$ reboot
Boot into SingleUser: <Cmd>+<s> on system start.
$ mount -uw /
$ mv /path/to/your/kext/AMDRadeonX3000.kext /AMD_KEXTS/
#### adjust the paths to what you found above and to what you did 2 months ago; after 10.12.6 update the /path/to/your/kext/AMDRadeonX3000.kext will very likely be: /System/Library/Extensions/AMDRadeonX3000.kext

$ sync
$ reboot

You should now boot verbose mode into an iGPU accelerated Sierra normal full boot.