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

[skiltrip]

working on this now. I'm stuck on deleting gpu-power-prefs...
trying the rm command gives me operation not permitted.
i try to umount and mount as rw. I get no errors with those commands, but trying to delete gpu-power-prefs again gives me the operation not permitted error.

 

[nsgr]

working on this now. I'm stuck on deleting gpu-power-prefs...
trying the rm command gives me operation not permitted.
i try to umount and mount as rw. I get no errors with those commands, but trying to delete gpu-power-prefs again gives me the operation not permitted error.

chattr -i gpu-power-prefs-fa4....

rm gpu-power-prefs-fa4....

 

[skiltrip]

chattr -i gpu-power-prefs-fa4....

rm gpu-power-prefs-fa4....

Cool. Thanks. Figured it out right after I posted too. It's always that way.

Did everything right but only got it to boot once. Then back to white screen. Ugh.

 

[nsgr]

Cool. Thanks. Figured it out right after I posted too. It's always that way.

Did everything right but only got it to boot once. Then back to white screen. Ugh.

Try boot Single User Mac OS X (Command + S) then:

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

reboot

 

[skiltrip]

Try boot Single User Mac OS X (Command + S) then:

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

reboot

Wow. that seems to have done the trick . thank you! and thanks to the OP. crossing fingers!

 

[MikeyN]

I installed the latest security update from El Capitan 10.11.6 and realized that the Macbook Pro did not freeze on the IOConsoleUsers ScreenLockState.

I did the install by the App Store -> Updates.

The AMDRadeonX3000.kext was placed back in /System/Library/Extensions.

I realized that the AMDRadeonX3000.kext (updated) did not have the file Info.plist and so it was not loaded in the reboot (rebuild cache) and did not freeze the Macbook Pro.

I downloaded secupd2017-003elcapitan.dmg, mounted the dmg image, and then opened the PKG file with the Pacifist. Yes, within AMDRadeonX3000.kext there is no Info.plist file.

Did Apple do it on purpose or was it a mistake?

https://support.apple.com/kb/DL1932?locale=en_US


Update:

I manually loaded the AMDRadeonX3000.kext (folder /DisableExtensions) and temperature decreased. This kext is previous to the kext of the last update.

Just to clarify: The way you phrased it: the old kext was in place and Info.plist got removed?
I think it needs to read. "The supposedly updated AMDRadeonX3000.kext was installed back in /System/Library/Extensions."
But Apple is not shipping anything resembling the common understanding for full replacement combo updates in the case of the AMD driver. The original kext is needed in its default place.
I noticed that before that there was a small difference but didn't look into it.

This is a mistake in my view.
But then it is a mistake that also happens with SecUpdate 2017-003 for Yosemite or the 10.12.6 Combo-update.
That's why I keep posting to mv back the kext before doing any Apple updates that might contain changes to AMD drivers.
You are now running (security) updated AMD drivers except AMDRadeonX3000.kext. At least that is the result on Sierra going from .0-base via ThisHack via Combo-update. It may be the same X3000 if the SecUpdate just shipped a cumulative update and the X3000 was already at the exact version on your system before.

I'll focus on AppleGraphicsPowerManagement.kext. I think this kext can solve the problem of lowering the temperature of the AMD video card without having to load AMDRadeonX3000.kext.

There are differences between Nvidia and AMD in the configurations.
Changing the values you can also reduce Nvidia's power consumption.

Get rid of OSX lag and run your Macbook Pro GPU at full speed
http://www.chromescreen.com/get-rid-of-osx-lag-and-run-your-macbook-pro-gpu-at-full-speed/

I look forward to that.
Wouldn't that mean that due to kext signing issues SIP will be an even bigger problem?
sudo kext-dev-mode=1
or
csrutil enable --without kext
Notice the red flags Apple raises on these "unsupported configurations"

 

[Simone2309]

Please perform a safe boot (hold Shift key when MBP reboots) and see if you can login to your normal account. Also, did you follow the steps in post #528? or in post #1?

Yes, I can login, but the screen is flickering.

I followed all the steps in post #1

Now I tried the steps in post #528, I have an SSD so the command:
*) cd /Volumes/HD/
doesn't work, i put instead:
*) cd /Volumes

after the command:
*) mv -v System/Library/Extensions/AMDRadeonX3000.kext AMD_Kexts/

it say "No such file or directory"

 

[MikeyN]

Yes, I can login, but the screen is flickering.

I followed all the steps in post #1

Now I tried the steps in post #528, I have an SSD so the command:
*) cd /Volumes/HD/
doesn't work, i put instead:
*) cd /Volumes

after the command:
*) mv -v System/Library/Extensions/AMDRadeonX3000.kext AMD_Kexts/

it say "No such file or directory"

cd /Volumes/HD/ # this is not about HDD vs SSD; HD stands for your root volume, perhaps "Macintosh HD"?

You didn't say at what step or in what mode you are now. Still in Recovery?
A flickering screen sounds like you are either logging in with all AMD drivers gone, in SafeMode or even without the proper nvram-variable. You may have to reapply the nvram variable and make sure that all other AMD-kexts are still in /System/Library/Extensions.

Anyway. Concerning your current question:
The following might duplicate steps already taken. Retake those steps.

Shutdown.
<cmd>+<r>+<s> #_Boot into SingleUserRecovery by holding these keys.
type:
csrutil disable #_disable SIP
nvram boot-args="-v" #_turn on verbose boot mode
reboot #_reboot with the following keys pressed:
<cmd>+<s> #_into normal SingleUser
When in SingleUser:
/sbin/mount -uw / #_make your startup volume mounted writable
mv -v /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/ #_notice the extra slashes
touch /System/Library/Extensions #_trigger kextcache update
sleep 128 #_makes you and your laptop wait a bit
sync
reboot

 

[Simone2309]

cd /Volumes/HD/ # this is not about HDD vs SSD; HD stands for your root volume, perhaps "Macintosh HD"?

You didn't say at what step or in what mode you are now. Still in Recovery?
A flickering screen sounds like you are either logging in with all AMD drivers gone, in SafeMode or even without the proper nvram-variable. You may have to reapply the nvram variable and make sure that all other AMD-kexts are still in /System/Library/Extensions.

Anyway. Concerning your current question:
The following might duplicate steps already taken. Retake those steps.

Shutdown.
<cmd>+<r>+<s> #_Boot into SingleUserRecovery by holding these keys.
type:
csrutil disable #_disable SIP
nvram boot-args="-v" #_turn on verbose boot mode
reboot #_reboot with the following keys pressed:
<cmd>+<s> #_into normal SingleUser
When in SingleUser:
/sbin/mount -uw / #_make your startup volume mounted writable
mv -v /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/ #_notice the extra slashes
touch /System/Library/Extensions #_trigger kextcache update
sleep 128 #_makes you and your laptop wait a bit
sync
reboot

Thanks for your time and sorry but I am new to these code world. And it is about one week that I am trying to not smash this mac.

After the step:

mv -v /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/

I get no such file or directory

Seams that the drivers are gone?! How I can get it back?

BTW the weird thing is that from the guess account seams all right, my idea was to use it but I cannot change nothing, it keeping say that my Admin Pw is wrong.

Thanks

 

[MikeyN]

After the step:

mv -v /System/Library/Extensions/AMDRadeonX3000.kext /AMD_Kexts/

I get no such file or directory

Seams that the drivers are gone?! How I can get it back?

BTW the weird thing is that from the guess account seams all right, my idea was to use it but I cannot change nothing, it keeping say that my Admin Pw is wrong.

That Guest account should not have any privileges whatsoever. Keep it that way.

We assume you are either in SafeMode or in SingleUser mode, i.e. you are accessing your root and boot-volume –not in Recovery– :

To find the missing kexts, quick check the contents of:
ls -la / #_output should contain the folder /AMD_Kexts
ls -la /AMD_Kexts #_output might contain the missing kexts, if you moved them previously there
ls -la /System/Library/Extensions/AM* #_output might contain the X3000 kext we are trying to move and the other driver files

If that all fails, time to get a bigger gun:
/usr/bin/find /System/Library/Ext* -iname AMDRadeonX3* # searches for the one kext
/usr/bin/find / -iname AMD* # searches for all AMD-files on the whole volume, this can take quite a while.

You now should know where the AMD kexts are.
If even the last command doesn't turn up anything the drivers seem really gone, that is deleted. To reinstall them you have to download the latest ComboUpdate and SecurityUpdate from Apple's site for your current system and apply them both. They contain the drivers and you have to then start over with: moving only the AMDRadeonX3000.kext.

 

[skiltrip]

Wow. that seems to have done the trick . thank you! and thanks to the OP. crossing fingers!

It was good while I updated El Cap (I re-imaged the computer while I was at it), installed some audio software. Then during one install the graphics glitched out. Colored lines and all that. I was pretty sure I successfully disabled the AMD card. Not sure what just happened.

Now it's back to white screening on boot.

 

[MikeyN]

It was good while I updated El Cap (I re-imaged the computer while I was at it), installed some audio software. Then during one install the graphics glitched out. Colored lines and all that. I was pretty sure I successfully disabled the AMD card. Not sure what just happened.

Now it's back to white screening on boot.

If your chip is in its early states of failing or the machine was heavily overheating before then it is entirely possible that the variable was in fact not properly applied or now simply deleted from NVRAM. AudioSoftware may be incompatible with the system (Sierra?).

It is always possible that the machine that has a thermal problem causing the AMD chip to fail prematurely also toasts the rest for good.

But while it may be the case that the whole machine went really bonkers while it did the heavy lifting you described it is also possible that you now just have to start over.

The most likely reasons are:
a) a replaced AMDRadeonX3000.kext from the updates
b) a deleted NVRAM variable


for a) Redo the SIP-dance from: #528 and prepare autoloading the kext via LoginHook as in Update2 from: #599
for b) To simplify re-applying NVRAM variables prepare and then use this script: #572

Be sure to always boot verbosely (sudo nvram boot-args="-v") since "white screen" does not tell you enough.
And in this state: I keep SIP permanently disabled.

 

[nsgr]

Just to clarify: The way you phrased it: the old kext was in place and Info.plist got removed?
I think it needs to read. "The supposedly updated AMDRadeonX3000.kext was installed back in /System/Library/Extensions."
But Apple is not shipping anything resembling the common understanding for full replacement combo updates in the case of the AMD driver. The original kext is needed in its default place.
I noticed that before that there was a small difference but didn't look into it.

This is a mistake in my view.
But then it is a mistake that also happens with SecUpdate 2017-003 for Yosemite or the 10.12.6 Combo-update.
That's why I keep posting to mv back the kext before doing any Apple updates that might contain changes to AMD drivers.
You are now running (security) updated AMD drivers except AMDRadeonX3000.kext. At least that is the result on Sierra going from .0-base via ThisHack via Combo-update. It may be the same X3000 if the SecUpdate just shipped a cumulative update and the X3000 was already at the exact version on your system before.

If this same security update for Sierra 10.12.6 also does not have the Info.plist in AMDRadeonX3000.kext, then I think it's on purpose.

I look forward to that.
Wouldn't that mean that due to kext signing issues SIP will be an even bigger problem?
sudo kext-dev-mode=1
or
csrutil enable --without kext
Notice the red flags Apple raises on these "unsupported configurations"

Security Update El Capitan put back AMDRadeonX3000.kext in /System/Library/Extensions. This kext do not have Info.plist. So, AMDRadeonX3000.kext not load.

Why did Apple forget to put together the Info.plist that is needed to load AMDRadeonX3000.kext? Very strange.

At first, after reboot, and after the screen loading graphics, I thought that Apple had fixed this problem of freezing in the IOConsoleUser ScreenLockState.

My happiness lasted little until the kextstat | grep AMD. I noticed that AMDRadeonX3000.kext was not automatically loaded. Then I saw that there was no Info.plist inside this kext.

If this same security update for Sierra 10.12.6 also does not have the Info.plist in AMDRadeonX3000.kext, then I think it's on purpose. Make the same mistake in more than one operating system would be a lot of lack of attention (by Apple).

Update:

Download macOS Sierra 10.12.6 Update (Post Date: Jul 19, 2017) has AMDRadeonX3000.kext with its respective Info.plist.
https://support.apple.com/kb/DL1930?viewlocale=en_US&locale=en_US

 

[MikeyN]

Security Update El Capitan put back AMDRadeonX3000.kext in /System/Library/Extensions. This kext do not have Info.plist. So, AMDRadeonX3000.kext not load.

Why did Apple forget to put together the Info.plist that is needed to load AMDRadeonX3000.kext? Very strange.

At first, after reboot, and after the screen loading graphics, I thought that Apple had fixed this problem of freezing in the IOConsoleUser ScreenLockState.

My happiness lasted little until the kextstat | grep AMD. I noticed that AMDRadeonX3000.kext was not automatically loaded. Then I saw that there was no Info.plist inside this kext.

If this same security update for Sierra 10.12.6 also does not have the Info.plist in AMDRadeonX3000.kext, then I think it's on purpose. Make the same mistake in more than one operating system would be a lot of lack of attention (by Apple).

Update:

Download macOS Sierra 10.12.6 Update (Post Date: Jul 19, 2017) has AMDRadeonX3000.kext with its respective Info.plist.
https://support.apple.com/kb/DL1930?viewlocale=en_US&locale=en_US

Please note that for 10.12.6
base install + combo update gives:
AMDRadeonX3000.kext: v15.18, 6.765.987 bytes (6,8 MB on disk)

just the combo update gives:
AMDRadeonX3000.kext: v15.18, 6.765.978 bytes (6,8 MB on disk)

 

[nsgr]

Please note that for 10.12.6
base install + combo update gives:
AMDRadeonX3000.kext: v15.18, 6.765.987 bytes (6,8 MB on disk)

just the combo update gives:
AMDRadeonX3000.kext: v15.18, 6.765.978 bytes (6,8 MB on disk)

I did not understand what you mean by this information.

I just put a note that the El Captina Security Update 10.11.6 does not have the Info.plist inside the AMDRadeonX3000.kext.

 

[MikeyN]

I did not understand what you mean by this information.

I just put a note that the El Captina Security Update 10.11.6 does not have the Info.plist inside the AMDRadeonX3000.kext.

My posting should convey the information:

Yosemite and El Capitan had AMD kexts updated that were incomplete if solely from the updater, as we noted, because at least the Info.plist file is missing.

If one goes the route of using Sierra then the X3000 in the Sierra update that you cited is also incomplete.
As shown with the different filesizes.

Even the ComboUpdate (~1,98 GB, you linked standalone 10.12.6 delta update at ~1.11 GB) is incomplete in at least AMDRadeonX3000.kext.
At least the file PkgInfo is missing there ion the kext of the update. (Granted: that file is less important: https://developer.apple.com/library...untimeConfig/Articles/ConfigApplications.html)

My conclusion: kext should reside in /System/Library/Extensions during any update to avoid losses due to Applesloppiness.
Indeed the whole ecosystem looks quite sloppy, or in your words: "would be a lot of lack of attention (by Apple)."

 

[Simone2309]

That Guest account should not have any privileges whatsoever. Keep it that way.

We assume you are either in SafeMode or in SingleUser mode, i.e. you are accessing your root and boot-volume –not in Recovery– :

To find the missing kexts, quick check the contents of:
ls -la / #_output should contain the folder /AMD_Kexts
ls -la /AMD_Kexts #_output might contain the missing kexts, if you moved them previously there
ls -la /System/Library/Extensions/AM* #_output might contain the X3000 kext we are trying to move and the other driver files

If that all fails, time to get a bigger gun:
/usr/bin/find /System/Library/Ext* -iname AMDRadeonX3* # searches for the one kext
/usr/bin/find / -iname AMD* # searches for all AMD-files on the whole volume, this can take quite a while.

You now should know where the AMD kexts are.
If even the last command doesn't turn up anything the drivers seem really gone, that is deleted. To reinstall them you have to download the latest ComboUpdate and SecurityUpdate from Apple's site for your current system and apply them both. They contain the drivers and you have to then start over with: moving only the AMDRadeonX3000.kext.

Well, with ls -la / I found that AMD_Kexts is in drwxr-xr-x

With /usr/bin/find / -iname AMD* it say:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory

What does it mean? How I can move it?

 

[nsgr]

My posting should convey the information:

Yosemite and El Capitan had AMD kexts updated that were incomplete if solely from the updater, as we noted, because at least the Info.plist file is missing.

If one goes the route of using Sierra then the X3000 in the Sierra update that you cited is also incomplete.
As shown with the different filesizes.

Even the ComboUpdate (~1,98 GB, you linked standalone 10.12.6 delta update at ~1.11 GB) is incomplete in at least AMDRadeonX3000.kext.
At least the file PkgInfo is missing there ion the kext of the update. (Granted: that file is less important: https://developer.apple.com/library...untimeConfig/Articles/ConfigApplications.html)

My conclusion: kext should reside in /System/Library/Extensions during any update to avoid losses due to Applesloppiness.
Indeed the whole ecosystem looks quite sloppy, or in your words: "would be a lot of lack of attention (by Apple)."

I just hope that Apple has not forgotten an Info.plist or other file in an important kext for operating system security.

 

[MikeyN]

Well, with ls -la / I found that AMD_Kexts is in drwxr-xr-x

That means you have successfully created the folder suggested in previous guides and that that is still there. At the root level of your volume (the characters drwxr-xr-x are the permissions.)

With /usr/bin/find / -iname AMD* it say:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory

What does it mean? How I can move it?

This is a bit tougher to answer.
First: these are harmless error messages generated because of the way the command was formulated.
But if you entered all of the commands given and the output you quoted was all there was then this is strange.
On your root volume it should have found a lot more, like:
/Applications/Automator.app/Contents/Resources/Base.lproj/AMDocument.nib

If you are sure you were doing that on your root volume and perhaps you just quoted the error messages because you didn't see the wanted kexts: then it looks to me like the AMD kexts are deleted and simply nowhere to be found on this volume.

That would mean you would have to reinstall the kexts. Not just move it. (Although that might be an option if you have backups containing them.)

If you do not know how to reinstall just the missing kexts your best bet is to reinstall the system.

Whether by install medium or via recovery-mode re-installation:

The NVRAM-fix should stay in place on its own.

But when the installation finishes you will have the AMD drivers all back, and all back to autoload on boot.
That means the guide you used has to be followed again from the point where it says to move AMDRadeonX3000.kext.

 

[nonlen]

Hi, I have the MBP 15" late 2011 and it's AMD gpu probably just died. This is a huge thread and to be honest, I'm quite confused....so my quick question is: Is the OP's # 1 post "100% working solution" still something I should try first? Or maybe post # 528? Or something else?

I'm on El Capitan 10.11.6 and I'm only able to boot my MBP using single mode and using "sudo nvram ..bla bla ..%00" command. After that, I'm able to boot to osx and use MBP as usual but if it crashes or shut down for some reason, I have to reboot in single mode and start all over again....

 

[Brandon316]

I didn't have the gpu-power-pref variable and added as shown. I then use ls to verify that it's there and follow with the unmounting and reboot. Still having the same problems however and when rebooting with my boot USB I run ls command again and the gpu-power-prefs variable is no longer there. Any idea what I'm doing wrong here?

I'm using a 2012 retina with Sierra.

Brandon

 

[yukari]

Hi, I have the MBP 15" late 2011 and it's AMD gpu probably just died. This is a huge thread and to be honest, I'm quite confused....so my quick question is: Is the OP's # 1 post "100% working solution" still something I should try first? Or maybe post # 528? Or something else?

I'm on El Capitan 10.11.6 and I'm only able to boot my MBP using single mode and using "sudo nvram ..bla bla ..%00" command. After that, I'm able to boot to osx and use MBP as usual but if it crashes or shut down for some reason, I have to reboot in single mode and start all over again....

I found this was the most effective for me (#426): https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-18#post-24798628

 

[Audit13]

@Brandon316, the 15.4" mid-2012 retina had an nVidia dGPU so I'm not sure this AMD fix will resolve your issue.

 

[MikeyN]

@Brandon316, the 15.4" mid-2012 retina had an nVidia dGPU so I'm not sure this AMD fix will resolve your issue.

We do not know the symptoms and to what end and after which guide Brandon approached the problem.
It is true that the most often linked to NVRAM variable will likely not be applicable. Different UUID, therefore discarded upon reboot.

However, if the goal is to force the iGPU to be used upon boot because the dGPU is flaky then the original approach with linux might still be valuable.

Exploring the efivars under linux might give some very valuable insight still.

 

[Audit13]

@MikeyN, this is true. I didn't think of it in those terms.