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

[nsgr]

It is incomplete but it works just like that after a successful boot. And no, i have no other hooks. But, if you clean nvram, the pc will bootloop due to rebuilding the gpu-... related files and activating the dGPU and not being able to boot to it. I edited my post with more info if you would like to re read it.
[doublepost=1501771268][/doublepost]Theorycrafting more into it, and assuming there is a logical structure into it, setting the gpu-power-prefs to (=) %07%00%00%00 instead of %01%00%00%00 would result into the dGPU being the primary boot gpu. But the main problem persists; MacOs overwrite that file on every reboot when not being specificly instructed to what to do.

The correct is (ArchLinux):

1 - Integrated video - Intel - %01%00%00%00

printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/.../gpu-power-prefs...


2 - Discrete video - AMD - %00%00%00%00

printf "\x07\x00\x00\x00\x00\x00\x00\x00" > /sys/.../gpu-power-prefs...



sudo nvram gpu-power-prefs=%01%00%00%00 - Does not create a gpu-power-prefs file on the EFI partition.

The correct format is: sudo nvram GUID:variable=value

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


With only sudo nvram gpu-power-prefs=%01%00%00%00 , Is the video card locked on the Intel video card? With gfxcardstatus, did you switch to Discrete Only and get locked on the Intel board?

 

[MikeyN]

With only sudo nvram gpu-power-prefs=%01%00%00%00 , Is the video card locked on the Intel video card? With gfxcardstatus, did you switch to Discrete Only and get locked on the Intel board?

What do you mean with "did you switch to Discrete Only and get locked on the Intel board?"
With the appropriate nvram setting the machine always stays in Intel, yes.
In gfxCardStatus I can select what I want, the check mark follows, but without effect on the chip actually in use.
Neither has switching on "Automatic Graphics Switching" in Energy Saver Preferences any effect.
Although the setting there reverts to unchecked as long as gfxCardStatus is loaded.
It remains the way I selected it if gfxCardStatus is unloaded.

 

[nsgr]

What do you mean with "did you switch to Discrete Only and get locked on the Intel board?"
With the appropriate nvram setting the machine always stays in Intel, yes.
In gfxCardStatus I can select what I want, the check mark follows, but without effect on the chip actually in use.
Neither has switching on "Automatic Graphics Switching" in Energy Saver Preferences any effect.
Although the setting there reverts to unchecked as long as gfxCardStatus is loaded.
It remains the way I selected it if gfxCardStatus is unloaded.

Simple:

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

versus

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

------------

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

This creates the gpu-power-prefs file on the EFI partition and adds the immutable attribute.


Update:

Real Test:

1 - Reset NVRAM / PRAM - Option + Command + P + R

Then the variable gpu-power-prefs will be erased from the EFI partition.

The primary video card at boot will be AMD discrete. Problems of red screen with white stripes.


2 - Boot Single user (Command + S)

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

reboot


3 - Boot normal.

Change to Discrete Only with gfxcardstatus and see if the video card remains locked at Intel or goes to the AMD video card and returns the video problem.

 

[MikeyN]

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

That is taken for granted by now and I already replied to the OP in similar direction (#595).

What I meant was:
There are different setups, different OSes, different methods and different states of failure on the AMD chip.

Do you describe your setup/situation as: after setting the right variable
– gfxCardstatus doesn't let you select "discrete only"
……(as I understood that part of your posting)
vs
– gfxCardStatus lets you select "discrete only" but it has no effect?
……(as I would describe my situation with gfxCardStatus 2.4.4i )

Here, after disabling dGPU, gfxCardStatus 2.4.4i happily accepts any given order, sets the check mark to the desired choice, but does nothing in regard to the chips in use. Therefore it is of very limited use to check anything.

[Update to your update:
without properly disabled dGPU/default EFI/NVRAM; here the symptom is blueish screen with black 'scan lines' and a checkerboard on the first and last line of pixels. And of course: full normal boot impossible now.
Update2 to your update:
Ah! So you select discrete, the app let's you do that, but ineffectively. Thanks for clearing that up.]

 

[nsgr]

That is taken for granted by now and I already replied to the OP in similar direction (#595).

What I meant was:
There are different setups, different OSes, different methods and different states of failure on the AMD chip.

Do you describe your setup/situation as: after setting the right variable
– gfxCardstatus doesn't let you select "discrete only"
……(as I understood that part of your posting)
vs
– gfxCardStatus lets you select "discrete only" but it has no effect?
……(as I would describe my situation with gfxCardStatus 2.4.4i )

Here, after disabling dGPU, gfxCardStatus 2.4.4i happily accepts any given order, sets the check mark to the desired choice, but does nothing in regard to the chips in use. Therefore it is of very limited use to check anything.

See the update of the post above. Real Test.
[doublepost=1501796592][/doublepost]See the update of the post above. Real Test.

That is taken for granted by now and I already replied to the OP in similar direction (#595).

What I meant was:
There are different setups, different OSes, different methods and different states of failure on the AMD chip.

Do you describe your setup/situation as: after setting the right variable
– gfxCardstatus doesn't let you select "discrete only"
……(as I understood that part of your posting)
vs
– gfxCardStatus lets you select "discrete only" but it has no effect?
……(as I would describe my situation with gfxCardStatus 2.4.4i )

Here, after disabling dGPU, gfxCardStatus 2.4.4i happily accepts any given order, sets the check mark to the desired choice, but does nothing in regard to the chips in use. Therefore it is of very limited use to check anything.

[Update to your update:
without properly disabled dGPU/default EFI/NVRAM; here the symptom is blueish screen with black 'scan lines' and a checkerboard on the first and last line of pixels]

That is taken for granted by now and I already replied to the OP in similar direction (#595).

What I meant was:
There are different setups, different OSes, different methods and different states of failure on the AMD chip.

Do you describe your setup/situation as: after setting the right variable
– gfxCardstatus doesn't let you select "discrete only"
……(as I understood that part of your posting)
vs
– gfxCardStatus lets you select "discrete only" but it has no effect?
……(as I would describe my situation with gfxCardStatus 2.4.4i )

Here, after disabling dGPU, gfxCardStatus 2.4.4i happily accepts any given order, sets the check mark to the desired choice, but does nothing in regard to the chips in use. Therefore it is of very limited use to check anything.

[Update to your update:
without properly disabled dGPU/default EFI/NVRAM; here the symptom is blueish screen with black 'scan lines' and a checkerboard on the first and last line of pixels]

Same thing here.
So I strange just use sudo nvram gpu-power-prefs=%01%00%00%00. This option does not create the gpu-power-prefs file in the EFI partition and adds the immutable attribute.

For me, the correct one is:

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

 

[MikeyN]

So I strange just use sudo nvram gpu-power-prefs=%01%00%00%00. This option does not create the gpu-power-prefs file in the EFI partition and adds the immutable attribute.

For me, the correct one is:

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

Yes. I do don't know that much about all possible variables in nvram or efivars. But we do know by now that the last line quoted above from you, nsgr, is a quite well proven step to success in our situation.
What, if anything, "sudo nvram gpu-power-prefs=%01%00%00%00 " does remains a mystery. The OP for this form of "fix" states in #594, #596, #598 that it does/works somehow something.
Unfortunately we do not know enough about the current situation there. Savroula said: "It is incomplete but it works just like that after a successful boot." Would be nice to know what that is.

 

[nsgr]

Yes. I do don't know that much about all possible variables in nvram or efivars. But we do know by now that the last line quoted above from you, nsgr, is a quite well proven step to success in our situation.
What, if anything, "sudo nvram gpu-power-prefs=%01%00%00%00 " does remains a mystery. The OP for this form of "fix" states in #594, #596, #598 that it does/works somehow something.
Unfortunately we do not know enough about the current situation there. Savroula said: "It is incomplete but it works just like that after a successful boot." Would be nice to know what that is.

Did Savroula do the Real Test? The proof is in doing the Real Test.

 

[Savroula]

Did Savroula do the Real Test? The proof is in doing the Real Test.

Sorry but rl get the best of me. The real test... more like what i tried. I cleaned the nvram just like your step 1. I booted once to archlinux and edited the efivars as indicated by the OP. After that, i reboot and it gets me in the OS X like normally and fully functioning.
Now, if i will reboot the machine like anyone would do normally,, it will hang and never load the OS X dgpu drive back, thus will bootloop after a while. On the other hand, if after the archlinux efivars editingi boot normally in os and open terminal, then input
Sudo nvram gpu-power-prefs=%01%00%00%00
Sudo reboot
The machine will reboot normally into the OS as if nothing had changed all the times i do it.
And one more hint as to what happens to efivars and rebooting:
As i said, rebooting resets the efivars eventhough it has chattr +i (for me at least)
Also as I said, inputting these 2 lines in terminal the booting is normal into igpu.
BUT if do the efivar editing, boot into the OS normally and hard power down the mbp (press the power button for long, forcibly cutting off the power of the mbp) and turn it on again, voila, it works as if nothing had ever changed and boots into the os normally in igpu. And that is why i suspect that during the shutdown phase of the macos, the efivars get reset to defaults for some reason.
I am off for today. Will discuss my experiments further tomorrow! Cheers!

 

[nsgr]

Sorry but rl get the best of me. The real test... more like what i tried. I cleaned the nvram just like your step 1. I booted once to archlinux and edited the efivars as indicated by the OP. After that, i reboot and it gets me in the OS X like normally and fully functioning.
Now, if i will reboot the machine like anyone would do normally,, it will hang and never load the OS X dgpu drive back, thus will bootloop after a while. On the other hand, if after the archlinux efivars editingi boot normally in os and open terminal, then input
Sudo nvram gpu-power-prefs=%01%00%00%00
Sudo reboot
The machine will reboot normally into the OS as if nothing had changed all the times i do it.
And one more hint as to what happens to efivars and rebooting:
As i said, rebooting resets the efivars eventhough it has chattr +i (for me at least)
Also as I said, inputting these 2 lines in terminal the booting is normal into igpu.
BUT if do the efivar editing, boot into the OS normally and hard power down the mbp (press the power button for long, forcibly cutting off the power of the mbp) and turn it on again, voila, it works as if nothing had ever changed and boots into the os normally in igpu. And that is why i suspect that during the shutdown phase of the macos, the efivars get reset to defaults for some reason.
I am off for today. Will discuss my experiments further tomorrow! Cheers!

Real Test does not say to boot into ArchLinux. Why did you boot into ArchLinux?

 

[Savroula]

Unfortunately we do not know enough about the current situation there. Savroula said: "It is incomplete but it works just like that after a successful boot." Would be nice to know what that is.

For that to work you have to first successfully boot into the os by editing the efivar through archlinux. Then you have to open the terminal and input this just before sudo reboot so the efivars do not get altered (somehow i guess. I remind you that i am a noob in the architectural matters still). Also i am curious as to the class guid and why gpu-power-prefs-... gpu-active-... and gpu-policy -... get their class guid altered after successfully booting into igpu.
One way to confirm it, would be if you follow the archlinux efivars editing, then boot into the OS, force hard shutdown by holding the power button, boot into archlinux again and explore the /sys/firmware/efi/efivars/ with ls. You will most probably have some altered efivars class guid as i did. If not, then it must have been an error.

 

[nsgr]

For that to work you have to first successfully boot into the os by editing the efivar through archlinux. Then you have to open the terminal and input this just before sudo reboot so the efivars do not get altered (somehow i guess. I remind you that i am a noob in the architectural matters still). Also i am curious as to the class guid and why gpu-power-prefs-... gpu-active-... and gpu-policy -... get their class guid altered after successfully booting into igpu.
One way to confirm it, would be if you follow the archlinux efivars editing, then boot into the OS, force hard shutdown by holding the power button, boot into archlinux again and explore the /sys/firmware/efi/efivars/ with ls. You will most probably have some altered efivars class guid as i did. If not, then it must have been an error.

Do the Real Test and post if it worked. Otherwise, the sudo nvram gpu-power-prefs=%01%00%00%00 procedure does not work.

Real Test = No boot in ArchLinux. Only Mac OS.

You have to choose only one method with Reset NVRAM / PRAM.

1 - ArchLinux

Or


2 - Boot Single User Mac OS and:

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

 

[Savroula]

Will do tomorrow. But as far as i remember, i did the realtest twice and the second time i was unable to boot in general, so i thinking that i might have done something wrong i procceded to a fresh instal of Lion.
Only thing that helped me was editing the efivars through linux first.
What i wanted to show you is the fact that efivars do get altered by macos always at shutdown and that by inputing this comman in the macos terminal, it would prevent the mbp booting into dgpu on the next reboot.

 

[nsgr]

Will do tomorrow. But as far as i remember, i did the realtest twice and the second time i was unable to boot in general, so i thinking that i might have done something wrong i procceded to a fresh instal of Lion.
Only thing that helped me was editing the efivars through linux first.
What i wanted to show you is the fact that efivars do get altered by macos always at shutdown and that by inputing this comman in the macos terminal, it would prevent the mbp booting into dgpu on the next reboot.

If you did the correct procedure in ArchLinux, then you do not need to do the sudo nvram gpu-power-prefs=%01%00%00%00.

If the settings are lost when restarting or shutting down the Macbook, then the procedure in ArchLinux is incomplete. You should have received some error message in ArchLinux and did not notice.

Most people here have trouble adding immutability correctly in the gpu-power-prefs file.


Take a simple test.

1 - Reset NVRAM / PRAM


2 - Boot Single user in Mac OS (Command + S)


If you miss any letter or number, then it will not work (fa4ce28d-b62f-4c99-9cc3-6815686e30f9).


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

sudo nvram boot-args="-v"

reboot

Remember, not boot in ArchLinux.

Then normal boot Mac OS, reboot or shut down Mac OS and see if the configuration remains for Intel video card.

If during the MacOS verbose boot freeze in IOConsoleUSER IOScreenLockState, then the problem is with AMDRadeonX3000.kext.

You can not keep the Apple logo. You have to put the boot verbose:

sudo nvram boot-args="-v"

 

[MikeyN]

If you did the correct procedure in ArchLinux, then you do not need to do the sudo nvram gpu-power-prefs=%01%00%00%00.

If the settings are lost when restarting or shutting down the Macbook, then the procedure in ArchLinux is incomplete. You should have received some error message in ArchLinux and did not notice.

Most people here have trouble adding immutability correctly in the gpu-power-prefs file.


Take a simple test.

1 - Reset NVRAM / PRAM


2 - Boot Single user in Mac OS (Command + S)


If you miss any letter or number, then it will not work (fa4ce28d-b62f-4c99-9cc3-6815686e30f9).


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

sudo nvram boot-args="-v"

reboot

Remember, not boot in ArchLinux.

Then normal boot Mac OS, reboot or shut down Mac OS and see if the configuration remains for Intel video card.

If during the MacOS verbose boot freeze in IOConsoleUSER IOScreenLockState, then the problem is with AMDRadeonX3000.kext.

You can not keep the Apple logo. You have to put the boot verbose:

sudo nvram boot-args="-v"

While in single user mode, you are effectively root. (Note the name of your prompt there: "root#")
So sudo is not necessary then.
An alternative might be to boot into safe-mode (<shift> on power-on/boot). Then you have a miserable GUI and have to use sudo. (https://support.apple.com/en-gb/HT201262)

And I second the need to always boot verbosely.

 

[nsgr]

While in single user mode, you are effectively root. (Note the name of your prompt there: "root#")
So sudo is not necessary then.
An alternative might be to boot into safe-mode (<shift> on power-on/boot). Then you have a miserable GUI and have to use sudo. (https://support.apple.com/en-gb/HT201262)

And I second the need to always boot verbosely.

Yes, it works too.

Honestly I think it would be better to do procedures in Safe Mode for people who are not accustomed to the Terminal.

Then you would use the simple Copy and Paste in Terminal. This would avoid typo.

I have not tried it, so I do not know if it is possible to move AMDRadeonX3000.kext with the Finder in Safe Mode. That would avoid many steps.

The only previous step would be to disable SIP (csrutil disable) in Recovery Mode text only (Command + R + S). - for El Capitan or Sierra.

http://txt.do/dox4x

 

[MikeyN]

Yes, it works too.

Honestly I think it would be better to do procedures in Safe Mode for people who are not accustomed to the Terminal.

Then you would use the simple Copy and Paste in Terminal. This would avoid typo.

I have not tried it, so I do not know if it is possible to move AMDRadeonX3000.kext with the Finder in Safe Mode. That would avoid many steps.

The only previous step would be to disable SIP (csrutil disable) in Recovery Mode text only (Command + R + S). - for El Capitan or Sierra.

As you implied, SIP related dances are not even necessary for Yosemite

Single user is way way faster compared to safe-mode.

Errors might happen. People need to be able to read and type.

For c&p: how to tell people where from they have to copy and paste the instructions and command sequences?
Can't remember and no time to test it right now:
According to https://support.apple.com/en-gb/HT201262 wifi may be limited.
According to http://hints.macworld.com/article.php?story=20080629044753419 wifi might be made available. (Link is quite outdated and actual hint contains inaccuracies, like typos.)

Also, I do not trust Finder for these operations. (Or any, really)
The /System-hierarchy is protected. So dragging the kext with Finder will either not move but copy it, changing ownership/permissions or make a link/alias. You could make the Finder run as root, thereby opening another can of worms and complicating things even more.

What would really simplify things is using an external disk (already present or prepared on another Mac) to manipulate the internal system drive. Or using the other Mac to just mount the defective MacBook's drive in target-disk-mode.
Then you can prepare moving AMDRadeonX3000.kext to a custom location and also place my script from #572 at the root of the filesystem. Skipping recovery mode and needing only a single single user mode boot. That speeds things up quite a bit and reduces the typo-threat.

 

[nsgr]

As you implied, SIP related dances are not even necessary for Yosemite

Single user is way way faster compared to safe-mode.

Errors might happen. People need to be able to read and type.

For c&p: how to tell people where from they have to copy and paste the instructions and command sequences?
Can't remember and no time to test it right now:
According to https://support.apple.com/en-gb/HT201262 wifi may be limited.
According to http://hints.macworld.com/article.php?story=20080629044753419 wifi might be made available. (Link is quite outdated and actual hint contains inaccuracies, like typos.)

Also, I do not trust Finder for these operations. (Or any, really)
The /System-hierarchy is protected. So dragging the kext with Finder will either not move but copy it, changing ownership/permissions or make a link/alias. You could make the Finder run as root, thereby opening another can of worms and complicating things even more.

What would really simplify things is using an external disk (already present or prepared on another Mac) to manipulate the internal system drive. Or using the other Mac to just mount the defective MacBook's drive in target-disk-mode.
Then you can prepare moving AMDRadeonX3000.kext to a custom location and also place my script from #572 at the root of the filesystem. Skipping recovery mode and needing only a single single user mode boot. That speeds things up quite a bit and reduces the typo-threat.

Errors might happen. People need to be able to read and type.

This is why this thread has 25 pages.


Why use wi-fi if it can have a text file on the pendrive with sudo nvram ...?

I'm using El Capitan and Sierra and the wi-fi works in Safe Mode. By the way, the wi-fi works even in Recovery Mode. Safari too.

The installer (pendrive) El Capitan and Sierra works with wi-fi and Safari. OS X Base System works with wi-fi.

What would really simplify things is using an external disk (already present or prepared on another Mac) to manipulate the internal system drive. Or using the other Mac to just mount the defective MacBook's drive in target-disk-mode.

Simple? Really?

 

[MikeyN]

Errors might happen. People need to be able to read and type.

This is why this thread has 25 pages.

That's true. Partially. There were important discoveries added, for example by you. And I think there are still improvements possible, not the least like we are discussing now.

Why use wi-fi if it can have a text file on the pendrive with sudo nvram ...?

Good point.
Saw the scenario as single Mac, AMD went bad the minute before, GUI-Boot only possible into safe or recovery, Pendrive not ready. But just the text file could even be copied from Win or Linux.

I'm using El Capitan and the wi-fi works in Safe Mode. By the way, the wi-fi works even in Recove Mode. Safari too.

Good. It was a very long time ago for me to use safe-mode for anything but strictly local trouble-shooting. It is so painfully slow.

What would really simplify things is using an external disk (already present or prepared on another Mac) to manipulate the internal system drive. Or using the other Mac to just mount the defective MacBook's drive in target-disk-mode.

Simple? Really?

IMHO. Yes. One unavoidable step seems to be booting into single user and issue an nvram command.
It seems not harder than that.
And what is a pen drive other but an external drive? The passage in bold above is as easy but usually faster. Most real disks are faster than USB sticks. Plus: We're talking early 2011 MBP here. No USB 2.0 device can beat firewire800 or Thunderbolt target disk mode.

Booting from anything other than regular boot volume or its recovery volume should circumvent SIP. At least that's what I did to quickly doctor Sierra and High Sierra into booting. No csrutil disable, reboot, csrutil enable.
See https://developer.apple.com/library...ion/ConfiguringSystemIntegrityProtection.html

 

[nsgr]

That's true. Partially. There were important discoveries added, for example by you. And I think there are still improvements possible, not the least like we are discussing now.



Good point.
Saw the scenario as single Mac, AMD went bad the minute before, GUI-Boot only possible into safe or recovery, Pendrive not ready. But just the text file could even be copied from Win or Linux.



Good. It was a very long time ago for me to use safe-mode for anything but strictly local trouble-shooting. It is so painfully slow.



IMHO. Yes. One unavoidable step seems to be booting into single user and issue an nvram command.
It seems not harder than that.
And what is a pen drive other but an external drive? The passage in bold above is as easy but usually faster. Most real disks are faster than USB sticks. Plus: We're talking early 2011 MBP here. No USB 2.0 device can beat firewire800 or Thunderbolt target disk mode.

Booting from anything other than regular boot volume or its recovery volume should circumvent SIP. At least that's what I did to quickly doctor Sierra and High Sierra into booting. No csrutil disable, reboot, csrutil enable.
See https://developer.apple.com/library...ion/ConfiguringSystemIntegrityProtection.html

Pendrive works fine with boot - Press Option on boot .

Pendrive works fine with Safe Mode - Press Shift on boot

Pendrive works fine with Recovery Mode - Command + R

I'm posting now in Safe Mode with the mounted USB key (pendrive) and open the text file with sudo nvram ... .

-----------------------------
What exists is a problem with Recovery Mode or Mac OS Installer (pendrive) and the AMD video card with red screen and white stripes.

You will be frozen on the gray screen. The Macbook will super warm up and shut down. So with this process, the AMD chip will "auto repair" and you will be able to boot again.

So people put the Macbook Pro inside a bag or blanket to "cook" Macbook Pro.

I thought that when turning off (Overheating), the Macbook forced the new boot for the Intel video card. But that does not happen.

The gray screen problem is AMD6000Controller.kext, AMDFramebuffer.kext and AMDSupport.kext - Recovery Mode or Mac OS Installer (pendrive) with boot AMD red screen with white stripes.
-----------------------------


In Safe Mode - no load AMD6000Controller.kext, AMDFramebuffer.kext, AMDSupport.kext and AMDRadeonX3000.kext - so no problem to get Graphical Interface with boot AMD red screen with white stripes.

Why have to rush to boot with the external disk instead of the pendrive? Do it once and do it well done.

View 4min 30 seconds - Youtube video

Reballing flip chip GPUs is ******** - the truth about dead laptop GPUs & repairing them.

 

[Savroula]

If you did the correct procedure in ArchLinux, then you do not need to do the sudo nvram gpu-power-prefs=%01%00%00%00.

If the settings are lost when restarting or shutting down the Macbook, then the procedure in ArchLinux is incomplete. You should have received some error message in ArchLinux and did not notice.

Most people here have trouble adding immutability correctly in the gpu-power-prefs file.


Take a simple test.

1 - Reset NVRAM / PRAM


2 - Boot Single user in Mac OS (Command + S)


If you miss any letter or number, then it will not work (fa4ce28d-b62f-4c99-9cc3-6815686e30f9).


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

sudo nvram boot-args="-v"

reboot

Remember, not boot in ArchLinux.

Then normal boot Mac OS, reboot or shut down Mac OS and see if the configuration remains for Intel video card.

If during the MacOS verbose boot freeze in IOConsoleUSER IOScreenLockState, then the problem is with AMDRadeonX3000.kext.

You can not keep the Apple logo. You have to put the boot verbose:

sudo nvram boot-args="-v"

So, did the test. After the test it booted just fine into os.
Next time, the last line was:
AirPort: Link down on en1. Reason 1 (Uknown Reason)
Then screen goes black and after that hangs on white screen.
Then I forcibly shut it down. Next boot (and every other boot) last line was:
Ethernet [AppleBCM5701Ethernet] Link down on en0.
Then the screen goes black and after that hangs on white screen.

Also, there are 2 lines above that i wanna mention if of any help:
Previous Shutdown Cause: 3
SMC: smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode

Also, after logging in macos, i tried gfxcardstatus switching to integrated only, but the white screen appears and the system hangs.

Doing real test again, i saw that all these lines show up on a successful boot but the mbp does not go white screen, but boots into os normally.

 

[MikeyN]

View 4min 30 seconds - Youtube video

Reballing flip chip GPUs is ******** - the truth about dead laptop GPUs & repairing them.

Great guy, entertaining watch. As usual.
But that makes me wonder several things.
First, how much of a 'fix' is reheating the GPU and how exactly does it work? "Bumps inside the little silver thing" is just such an adorable explanation. If it is like in his metaphor "like a piece of wood against a wall" then I'd call this the "Apple-level fix", as it seems have a similar projected life span. If I were to reheat the the chip and apply higher quality thermal paste, how long would that hold?

Second, in this video he says that there are no new chips available anymore. Then I saw one where he stated that they would not do this anymore to 2011 MBP. Then I saw another, later one, where he had a bunch of new chips, still on a roll, applying them in a demo soldering to make a 2011 "like new again". That was confusing.

Third, I'd like to keep this machine going for a while. Matte hi-res screen, practically new battery, maxed out RAM and SSD. If I were to invest anything further in this machine on this kind of hardware level, then I wonder why not change the AMD-chip to something new, swap that capacitor thing also mentioned in this thread and upgrade the CPU at the same time? Take the maximum step up provided the pinouts are compatible. Why are there no reports for that out here? If a repair swapping the GPU is already at 300$ to avoid buying a recent but unattractive Touchbar then why not put up the extra money for a better CPU if you already pay the labor?

 

[Savroula]

Great guy, entertaining watch. As usual.
But that makes me wonder several things.
First, how much of a 'fix' is reheating the GPU and how exactly does it work? "Bumps inside the little silver thing" is just such an adorable explanation. If it is like in his metaphor "like a piece of wood against a wall" then I'd call this the "Apple-level fix", as it seems have a similar projected life span. If I were to reheat the the chip and apply higher quality thermal paste, how long would that hold?

I have performed quite a number of heating gpus in order for them to work. Long story short (along with my bad english): inside the chips, there are solders connecting the pins etc etc within it. Electric current is NOT massless so going through the chip, friction is applied overtime as well as heat. Chips like GPUs are getting hot (while operating) and cold (while off) all the time thus dilation and contraction do apply on some miniscule scale, but it is existent and this causes cracks between the solderings or even breaks them completely (Of course companies do take that under consideration and use proper or acceptable raw materials for those chips - you can find related images on google). When you heat the chip, the solderings (that have a lower melting point that the silicon of the chip) melt and solder back together within the chip. Though it is critical NOT to heat the chip too much (no more than about a minute, but tat depends on your heat source as well cuz there is a difference between using an over, an iron and a flame pistol) or the chip itself and mostly within will form wrong paths for soldering to come together (Talking about nanometers wide). !Be sure to cover everything apart from the chip-to-be-heat in aluminium foil, in order to prevent the pcb from melting!
As for the how much of a fix it is, i have observed that after heating, most chips are good for about a year, others are for less. After that the life expectancy is halved every time you heat the chip. So it is doomed to fail completely at at some point.
I have only done this fix for failing GPUs.

 

[Audit13]

@MikeyN, I'm not sure if new GPUs are available for this Macbook but the person that replaced mine said that the replacement he installed in mine was a late 2016/early 2017 model. Unfortunately, I didn't have a chance to see the board before he put it back together. I would remove the motherboard to look but there is security/warranty tape over the screws.

The GPU could not changed to a another model because the pin contacts would not match up with the motherboard and would have different electrical requirements that the motherboard can't mery. This is according to the repair tech.

For the cpu, the motherboard would not support a newer model as the electrical requirements for newer processors have also changed. Then there is the issue of socket and chipset support.

I can't say whether all of this is or isn't true, but I believe some of this information is accurate.

 

[MikeyN]

@MikeyN, I'm not sure if new GPUs are available for this Macbook but the person that replaced mine said that the replacement he installed in mine was a late 2016/early 2017 model. Unfortunately, I didn't have a chance to see the board before he put it back together. I would remove the motherboard to look but there is security/warranty tape over the screws.

The GPU could not changed to a another model because the pin contacts would not match up with the motherboard and would have different electrical requirements that the motherboard can't mery. This is according to the repair tech.

For the cpu, the motherboard would not support a newer model as the electrical requirements for newer processors have also changed. Then there is the issue of socket and chipset support.

I can't say whether all of this is or isn't true, but I believe some of this information is accurate.

According to memory a swap from same generation GPU design and same pinout and same tdp etc., e.g. from 6490 to 6770 or thereabout, should be feasible. At least the video from #551 was uploaded in March this year and there he talks about steppings.

I have seen a CPU swapped Core2Duo in an old Lenovo. Same generation, later stepping, slightly higher TDP, but vastly faster clockspeed. That was an incredible jump.

At least SandyBridge isn't that different from IvyBridge. Ivy is running cooler.
Sandy: http://ark.intel.com/products/53463
Ivy: http://ark.intel.com/products/64901
Same FCBGA1224, higher temps allowed on chip but even lower TDP…
There are different stories out there. Some reporting success, some not so. In a Lenovo forum I read speculation that there is a BIOS-lockdown to SandyBridge. But then there is this:

Of course this might not be that easy in how it would be done in a MBP.
Then who knows if there is some quirky kind of lockdown in Apple's EFI.

 

[Audit13]

@MikeyN, a bios update would probably be needed for a cpu upgrade from sandy to ivy and, without Apple support, it may not work but I really don't know enough to provide a definitive answer.

I'm just happy my repaired unit is still working.