Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Macbook Pro Early 2011 - Intel HD 3000 and AMD Radeon HD 6750M - Mac OS Sierra 10.12.5

Some people are not able to load Arch Linux correctly, so I decided to write this information.
I'm still testing.

I had to clear NVRAM (Option + Command + P + R) and the gpu-power-prefs setting was cleared from efivars.

No problem, Now I know how to do it (efivars modification in ArchLinux).

But I'm having a temperature rise problem of 20 degrees Celsius. This I resolve after investigating gpu-policy.

In short, I researched some information (AppleMacFinder, FGuarani, gmux-scripts, gpu-switch) again and fell into a Wikileaks page with the nvram variables after searching gpu-policy and boot-args = "argc = 1" on Google.

I had tried without success the famous sudo nvram gpu-power-prefs=%01%00%00%00 .

Now I have discovered that there is a way to do this. And it is not listed later in nvram -p .

Format:

sudo nvram GUID:NVRAM_Variable=value

GUID - Standard Apple Macbook Pro Early 2011-> fa4ce28d-b62f-4c99-9cc3-6815686e30f9

NVRAM Variable -> gpu-power-prefs

Value for Integrated gpu - In this case Binary data Hexadecimal (%) -> %01%00%00%00

Test: Single-User mode (Command + S) with red background screen and white stripes.


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


After the reboot, the screen became normal again.


Setting NVRAM Variables from OS X - Wikileaks
Example: DriverOrder

sudo nvram 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:DriverOrder=%00%50

https://wikileaks.org/ciav7p1/cms/page_26968084.html

http://www.insanelymac.com/forum/topic/291655-ozmosis/page-3

https://github.com/erikberglund/AppleNVRAM

https://github.com/gdbinit/firmware_vault

gmux-scripts - user Sprin commented on Dec 25, 2014
https://github.com/ah-/gmux-scripts/issues/1#issuecomment-68113930

gpu-switch
https://github.com/0xbb/gpu-switch/blob/master/gpu-switch

nvram-dump
https://github.com/ah-/nvram-dump/blob/master/nvram-dump.m

dmpstore - Variables EFI

http://en.community.dell.com/techcenter/os-applications/f/4457/t/19589262

https://forums.macrumors.com/thread...o-bios-emulation.696523/page-42#post-20529412

http://www.sysadminshare.com/2012/01/efi-shell-commands.html


Update from the future ( 11 july 2017) :


This procedure remains until Reset NVRAM / PRAM (Option + Command + P + R) .

My test on Macbook Pro Early 2011:

One week of reboots and shutdowns and the configuration remains active and running correctly (gpu-power-prefs -> Intel video card)

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
Thanks a ton @nsgr for this and @AppleMacFinder for the ArchLinux solution. Can confirm this works with the Mid-2014 750M MacBook Pro as well - assuming the appropriate kexts are moved (for persistence across boots). This can be useful for High Sierra as well because loaded NVIDIA kexts prevent native AMD eGPU acceleration to work on Macs with discrete NVIDIA graphics: https://egpu.io/forums/mac-setup/nvidia-workaround-for-high-sierra-egpu-acceleration/#post-17121 - decided to convert it into a tiny script for NVIDIA-only macs.
 
Last edited:
I had the 6770m replaced in my MBP. The chip was already defective and reflowing would do nothing to resolve the issue. He said he replaced the existing chip with an updated revision of the same chip and it should be good for a few years.

Not sure why installing a new GPU would cause the new GPU to fail sooner. How did your technician make this determination? Has he replaced and reflowed many of these failed MBPs?

Does your technician have the equipment to remove the existing GPU or would s/he send it out?

When you say "would do nothing to resolve the issue" - do you mean that your tech detected that the AMD was defected, and said reflowing will NOT solve the issue, even not temporarily ?

In my case it solved the problem for now, I don't know for how long it will still work. From what I understand from my tech, the condition of the GPU was good, and removing it totally would potentially create more risk for this fix to fail in the future... He did say however that reflowing doesn't fix it forever though. He has all "pricey" equipment that is used to replace GPUs...

I think it initially overheated as a result of the clogged fan exhausts, and the cheap white paste that has been placed under the GPU's heatsink - which makes me actually realize that it has been "fixed" before at some point... (I know it had a GPU issue in the past and that it was sent for repair, but I thought they replaced the motherboard, which doesn't seem to be true).

I'm looking for the best way to make it last as long as possible at this point.
 
No matter what I tried, I could never get the MBP to boot with the existing GPU.

I was not really interested in a software fix or reflowing. I left it with my repair guy for a possible reflow or replacement. He called to say that he could not get it going at all with the existing GPU even with a quick reflow so I told him to replace it as I wasn't really interested in a temporary reflow fix. The cost of the GPU replacement was $500 CAD with a 1 year warranty. I know it seems costly to replace the GPU but I bought this unit from Kijiji for $65.

I've been using the machine for a couple of weeks and it's running perfectly and switches between the iGPU and dGPU seamlessly.
 
When you say it will surely "break" again if been reflown... is it highly likely to happen?

My technician said he'd rather reflow than replace the entire GPU, as from his experience the act of replacing the GPU may even increase the chances that the problem returns... what do you think ?

How can I prevent it from failing again ? or what's the best I can do to make it work for as long as possible ?

Is failing again is a result of how much heat will be created inside the computer in the future ? what will happen if I run Macs Fan Control on high RPM constantly from now on, to keep it cooler than in automatic mode?

That explanation is a bit dubious? From my understanding it is just the other way around.
You cannot prevent it from failing again.
It already is a failed chip. It is broken. Now in a state, alright, that looks OK. Cf. #622, among others.
If your tech has applied good quality thermal paste in the proper way, which is not the Apple way, mind you, that is a start. Thermal management of the whole unit is important. A more aggressive fan control sure helps, too. Doing that myself.
Always keep it on hard, flat surface, do not use it in the summer unless the surroundings are air conditioned… Keep it cool, clean it regularly (inside the fans and fins). Abstain from dual monitor setups, rendering, gaming etc.
Apple sold you a lemon. They knew that. Apple fixed it up with another lemon. And they knew it. Now they left you in the rain. And they knew it would happen.
It is actually more important now to tell this to other people and to factor this into your next buying decision and voting decision than to put too much hope into all these hacking solutions. These have bought you time, but the days are numbered.
 
If you don't have time to read my story (which also describes some interesting technical approaches) just scroll down this thread until a "100% WORKING SOLUTION" text

Discrete AMD GPU of my 2011 MacBook Pro 8,2 has finally failed because of the reasons mentioned here ( http://logicboardmac.blogspot.ru/ ) and there ( https://www.macrumors.com/2015/02/19/2011-macbook-pro-repair-program-apple/ ) . It has been working perfectly for 6 years under quite a high load, even tried SETI@HOME mining at background! So I was confident that my MBP is not affected by bad solder / bad soldering quality and didn't want to bring it to Apple for a free repair program - partially because couldn't find the time to pause my important software projects, partially because I was afraid that Apple might give me a less reliable logic board or refuse a free repair because of the several unrelated repairs that I did manually by myself earlier to save money: changed thermal paste a few times, replaced the internal battery 2 times, replaced a keyboard with broken buttons, etc. But it finally broke down last week: laptop's screen image became distorted, it refused to boot OS X (always freezing half-way), and - Apple free repair program has already ended! I know there are affordable solutions like $50 BGA resoldering at unofficial local repair shop and that its possible to get a new replacement HD 6750M chip from AliExpress for $35 or cheaper ( http://www.aliexpress.com/item/DC-2...0028-216-0810028-BGA-Chipset/32764872143.html or https://www.aliexpress.com/item/DC-2015-New-216-0810001-216-0810001-Graphic-Chipset/32718112928.html , because don't know if this is true - https://www.rossmanngroup.com/board...0604-replace-216-0810005-gpu-with-216-0810028 ) to guarantee a successful repair, so the total price of repair would be either $50 or $50+$35=$85 - less than $100 in any case. But I don't like investing money to the old computers, so I have thought - what if there is some hack to force MBP to use integrated graphics ALL THE TIME, even while booting ? And then started to explore the possible solutions...

===

First of all, it is possible to successfully boot a MBP to OS X while still using the failed GPU, after you remove the AMD drivers by booting in command line mode (CMD+S) and entering these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot

The degree of your inconvenience while doing these steps - strongly depends on how heavily a screen's image is distorted in your case. In my case it was even more difficult because the OS X partition became a "read-only" partition (because of too many emergency shutdowns I did while desperately trying to boot OS X with a failed GPU) so I had to remove a hard drive from MacBook Pro and (using a USB to SATA 2.5" adapter taken from my portable HDD) attached it to a computer with Linux, then followed these instructions:

https://superuser.com/questions/961401/mounting-hfs-partition-on-arch-linux (1st answer) - carefully executed a number of commands, calculated a sizelimit for my parition layout, and finally ran sudo mount -t hfsplus -o force,rw,sizelimit=YOURNUMBER /dev/sdb2 /mnt to mount this HFS+ partition to /mnt directory in read-write mode. Then I performed these "1)-7)" steps you see above, and also repaired a filesystem by running sudo fsck.hfsplus -f /dev/sdb2 before unmounting a partition with sudo umount /mnt and putting a hard drive back to MBP...

===

This gave me a MBP which could boot to OS X although STILL using a broken AMD GPU: so it screen's image is very distorted (could browse the Internet but quite inconvenient to read a text), Launchpad is super laggy, and you can't switch to Integrated GPU using gfxCardStatus because: without AMD drivers (which we had to remove to successfully boot to OS X) Macbook Pro thinks its' internal screen is External Display and gfxCardStatus tells it is impossible to switch because External Display is using AMD GPU. Somewhere I found a suggestion that it is possible to rebuild a gfxCardStatus from the source code - https://github.com/codykrieger/gfxCardStatus - with removed or commented out 156-166 lines in the ./gfxCardStatus/Classes/GSProcess.m to make it to ignore the external display:

// find out if an external monitor is forcing the discrete gpu on
CGDirectDisplayID displays[8];
CGDisplayCount displayCount = 0;
if (CGGetOnlineDisplayList(8, displays, &displayCount) == noErr) {
for (int i = 0; i < displayCount; i++) {
if ( ! CGDisplayIsBuiltin(displays))
[list addObject:[NSDictionary dictionaryWithObjectsAndKeys:
Str(@"External Display"), kTaskItemName,
@"", kTaskItemPID, nil]];
}
}


So I rebuilt a gfxCardStatus using the instructions from the last reply of this issue -
https://github.com/codykrieger/gfxCardStatus/issues/229
(also had to download a MacOSX10.11.sdk from here - https://github.com/phracker/MacOSX-SDKs/releases - unpack and copy it to XCode's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk - because of the Apple's stupidity the latest XCode for El Capitan does not include SDK for El Capitan!) However, it still didn't work - gfxCardStatus only pretended that it has switched to Integrated GPU, while in reality OS X did not let it switch! Even after I edited ./gfxCardStatus/Classes/GSGPU.m file to enable the mysterious "Nuke it from orbit switching" option, it still couldn't switch...

===

Then I discovered this interesting repository - https://github.com/0xbb/gpu-switch - which is partially similar by its' source code to gfxCardStatus but also has the "Login Hooks" (install_hooks.sh) to "automate the switching process for login/logout". Sadly it didn't work for me... However, there is a very interesting gpu-switch text file right at the root of this repository, which describes the EFI variables!

https://github.com/0xbb/gpu-switch/blob/master/gpu-switch

After studying it and also reading this issue's comments - https://github.com/0xbb/gpu-switch/issues/11 - I became confident to try this solution, but found out that my MacBook Pro 2011 8,2 with OS X El Capitan 10.11.6 is in a VERY problematic situation:

1) rEFInd is not installed, and to install it - must disable SIP protection. But I cannot boot to Recovery mode (Command+Option+R) or to OS X Installation DVD/USB (hold Option), (to disable SIP), because they freeze while booting! - although I removed AMD kexts from my system, of course these recovery tools are using AMD kexts integrated to their design. Also cannot use Rootfool hack ( https://github.com/gdbinit/rootfool ) to disable SIP during runtime, because it works only at OS X version older than 10.11.4

2) Tried overheating my Macbook Pro on purpose (forcing CPU usage to 100% and putting it to a tightly closed bag) to force it to shutdown from overheating and then quickly reboot so that Integrated graphics will be enabled during the boot time - making it possible to boot to Recovery. But because of the wonderful high end thermal paste I have applied not so long ago - cannot overheat it even after waiting for a long time! At this point I thought that could either: a) remove AMD kexts from Installation media, or b) to connect MBP's hard drive to a Linux machine again and run a bunch of chmods to remove the SIP flags from the directories mentioned here ( http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really ) which could potentially make a system unbootable, or c) to try installing rEFInd to HFS+ partition directly from a Linux machine with root rights because it will bypass SIP --- but have not explored these options, although some of them might have worked...

3) Wanted to boot a Linux LiveCD to edit the EFI variables from there, but no matter what I did: tried booting straight without GRUB option modifications, tried editing GRUB boot options (with "e" key) to add nomodeset / remove quiet splash / or both in every combination , or like suggested in this article ( https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011) ) also add i915.modeset=0 radeon.modeset=0 or radeon.modeset=0 i915.modeset=1 i915.lvds_channel_mode=2 ; and then pressed Fn+F10 or Shift+Ctrl+Fn+F10 to boot with these options: but the Linux boot process always failed at different boot stages, no matter what popular user-friendly Linux distribution or what version of it I am trying: tried many releases of Ubuntu / Lubuntu / Fedora , even the old "AMD64 Mac" and "Alternate AMD64 Mac" images, but they always failed - either at the very beginning of boot process (black screen, or a black screen with a blinking or stuck _ character at the left upper corner) or failed at the very end of it - right before it is supposed to show a graphical desktop environment...

Later, totoe_84 wrote that he was able to boot Ubuntu in graphical mode using the following setup for GRUB:
  • To disable the AMD graphics card I added the following lines after set gfxpayload=keep
outb 0x728 1
outb 0x710 2
outb 0x740 2
outb 0x750 0
  • Next I added the following after quiet splash
    i915.lvds_channel_mode=2 i915.modeset=1 i915.lvds_use_ssc=0
(based on https://ubuntuforums.org/showthread.php?t=2157775 )

===

Then I remembered that there are not-mainstream Linux distributions for advanced users, which have a LiveCD without any graphical interface: you are dropped to a pure console and you are supposed to install the system along with only those graphical interfaces and software packages / groups of packages which you explicitly select. For example: Arch Linux (https://www.archlinux.org/) and Gentoo Linux (https://gentoo.org/) . Because their LiveCD does not have a graphical interface, they could be booted without a problem to a pure Linux console and there you could edit the EFI variables ! So here is a...

===
=== 100% WORKING SOLUTION
===
=== Force your MBP to ALWAYS use Intel integrated GPU (EFI variable fix)
===
=== to make it great again ! ;)
===


1) Create the Arch Linux LiveCD/LiveUSB :

You need a working computer for that and a spare CD/DVD/USB drive. Download the latest Arch Linux ISO image from this page - https://www.archlinux.org/download/ , at the time of writing it is archlinux-2017.03.01-dual.iso . Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB: use the great detailed instructions from this page, https://wiki.archlinux.org/index.php/USB_flash_installation_media

2) Boot to it: insert this CD/DVD/USB to Macbook Pro, hold Option key while booting, choose "EFI boot" (that is your bootable installation media), press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter. If everything is done correctly, you will find yourself at the Linux console!

3) Edit EFI vars: looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a "gpu-power-prefs-..." variable (where ... is UUID of this variable). If there is such a variable, its better to remove it with rm. In my case the efivarfs has been mounted by default with read/write permissions, but if you are getting the "operation not permitted" message while attempting to rm, it means that in your case efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again (credits to totoe_84 for this valuable addition) :
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/

If your screen is so distorted that it is difficult to see the letters, just start typing the rm gpu-power-pre and then press TAB key for autocompletion. In my case there were not such a EFI variable, only "gpu-active-..." and maybe somehow related "gfx-saved-config-restore-status-..." . Then I looked again at that gpu-switch text file (mentioned above, https://github.com/0xbb/gpu-switch/blob/master/gpu-switch),
and entered THESE COMMANDS:

*) chattr -i "/sys/firmware/efi/efivars/" <----- skip this command

Actually a gpu-switch script had "${sysfs_efi_vars}/${efi_gpu}" but I didnt have a "gpu-power-prefs-..." variable - so, partially by mistake, I didn't add that efi_gpu suffix and entered this incomplete path accidentally

*)
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a gpu-switch script

*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"

http://www.tecmint.com/chattr-command-examples/ - chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
...
Syntax of chattr ---> chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (+i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...
Operator
  1. + : Adds the attribute to the existing attribute of the files.
  2. : Removes the attribute to the existing attribute of the files.
  3. = : Keep the existing attributes that the files have.
This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances

*) cd /

Could not unmount efivars if you are inside this directory, so change to the root directory

*) umount /sys/firmware/efi/efivars/

Guarantees that your EFI variables are flushed to efivarfs filesystem, please unmount it safely before rebooting)

*) reboot

===> IF YOU DID EVERYTHING CORRECTLY, MOST LIKELY THAT YOUR MACBOOK PRO IS NOW USING INTEGRATED GRAPHICS WHILE BOOTING, AFTER BOOTING, AND IS WORKING GREAT AGAIN ! ;)

In the future maybe you could need to re-apply this solution if you would have to reset your PRAM / NVRAM / SMC because of some other problems, so remember this solution somewhere... Funny thing: now you can't switch to Discrete GPU even using gfxCardStatus, it is forever stuck at Integrated


I spent two working days to discover this solution, and really hope that it will work flawlessly for every MBP owner with a broken discrete GPU. Good luck!
[doublepost=1502329941][/doublepost]Thanks for the awesome post!!! Could someone please help me figure out why it stops working after computer is restarted.
Thank you
 
Quick note that moving GPU drivers/kexts (for example, for discrete graphics to prevent them from loading) on macOS High Sierra Beta 5 prevents boot. I have been unsuccessful so far to boot this build with iGPU after moving the kexts. The nvram variable changes still take effect though - so a single boot does result in iGPU-only behavior, but a reboot restores automatic graphics switching.
 
Quick note that moving GPU drivers/kexts (for example, for discrete graphics to prevent them from loading) on macOS High Sierra Beta 5 prevents boot. I have been unsuccessful so far to boot this build with iGPU after moving the kexts. The nvram variable changes still take effect though - so a single boot does result in iGPU-only behavior, but a reboot restores automatic graphics switching.


Works for me in High Sierra for the AMD solution of this thread. Boots exactly as desired. And nvram stays across reboots.
How much time did you allow for your invoke_kext_caching() subroutine when applying your script?
Not letting this finish properly hosed two installs here. At least for now High Sierra seems to be even less robust there.
According to ee6e9a1 you now use the kextcache command manually/via the script.
That plainly destroyed my installs here. Whether from High Sierra or from Sierra for High Sierra.
On the other hand only issuing touch /System/Library/Extensions and waiting worked.
 
Last edited:
Works for me in High Sierra for the AMD solution of this thread. Boots exactly as desired. And nvram stays across reboots.
How much time did you allow for your invoke_kext_caching() subroutine when applying your script?
Not letting this finish properly hosed two installs here. At least for now High Sierra seems to be even less robust there.
According to ee6e9a1 you now use the kextcache command manually/via the script.
That plainly destroyed my installs here. Whether from High Sierra or from Sierra for High Sierra.
On the other hand only issuing touch /System/Library/Extensions and waiting worked.

The kextcache -update-volume command just waits for the touch /System/Library/Extensions/ command (that invokes caching) to finish (mentioned in the man page of kextcache)... Alternatively to wait manually, I also used sudo reboot instead that waits for disk lock. In both cases, same results: Beta 5 boots halfway - then a spinning loading icon shows up below the loading bar and this state is indefinite.

The script works on Sierra 10.12.6 and also did on High Sierra B4 for me. Then perhaps its an NVIDIA problem on Beta 5?
 
The kextcache -update-volume command just waits for the touch /System/Library/Extensions/ command (that invokes caching) to finish (mentioned in the man page of kextcache)... Alternatively to wait manually, I also used sudo reboot instead that waits for disk lock. In both cases, same results: Beta 5 boots halfway - then a spinning loading icon shows up below the loading bar and this state is indefinite.

The script works on Sierra 10.12.6 and also did on High Sierra B4 for me. Then perhaps its an NVIDIA problem on Beta 5?

I cannot testify for or against Nvidia kexts in this context. But I filed the manual invocation of kextcache (which is discouraged anyway)* as dangerously buggy in High Sierra. It works as described for me in Yosemite also.
It never worked in High Sierra for me. Only touching the extensions folder did. Then looking at top to wait for the automatically system-invoked kextcache process to finish.
If it still gets you trouble that way, try booting verbose mode: <Cmd>+<v> on boot or
sudo nvram boot-args="-v"
to better identify the complaints your OS gives you.

___
*)Quote from manpage kextcache as present on 10.10:
The kextcache program creates kext caches, which speed up kext loading
operations. It is invoked automatically as needed to rebuild system
caches.
Caution: Incorrect use of kextcache can render a volume incapable of
startup. Installers and administrators should not use this program to
update system kext caches. Instead they should run touch(1) on the
/System/Library/Extensions/ directory of the installation target volume
after they have finished, which invalidates the existing caches and
causes the system to update all necessary kext caches.

 
Last edited:
I cannot testify for or against Nvidia kexts in this context. But I filed the manual invocation of kextcache (which is discouraged anyway) as dangerously buggy in High Sierra. It works as described for me in Yosemite also.
It never worked in High Sierra for me. Only touching the extensions folder did. Then looking at top to wait for the automatically system-invoked kextcache process to finish.
If it still gets you trouble that way, try booting verbose mode: <Cmd>+<v> on boot or
sudo nvram boot-args="-v"
to better identify the complaints your OS gives you.

Thank you @MikeyN for your insightful suggestions. I shall give them a shot soon and update.
 
I have the MacBook Pro (15-inch, Early 2011) and it's the second time I have a problem, the first time I took the apple and I changed the card, now they are not trading anymore.

Today I made the solution with Arch Linux, everything working with MAC OSX, however I use the bootcamp with windows 8.1, when it starts it comes the black screen! I tried to go up in safe mode, but I did not succeed. I think he has the AMD video card set up, but I can not get it to start without using it, did anyone have it?
 
I cannot testify for or against Nvidia kexts in this context. But I filed the manual invocation of kextcache (which is discouraged anyway)* as dangerously buggy in High Sierra. It works as described for me in Yosemite also.
It never worked in High Sierra for me. Only touching the extensions folder did. Then looking at top to wait for the automatically system-invoked kextcache process to finish.
If it still gets you trouble that way, try booting verbose mode: <Cmd>+<v> on boot or
sudo nvram boot-args="-v"
to better identify the complaints your OS gives you.

___
*)Quote from manpage kextcache as present on 10.10:
The kextcache program creates kext caches, which speed up kext loading
operations. It is invoked automatically as needed to rebuild system
caches.
Caution: Incorrect use of kextcache can render a volume incapable of
startup. Installers and administrators should not use this program to
update system kext caches. Instead they should run touch(1) on the
/System/Library/Extensions/ directory of the installation target volume
after they have finished, which invalidates the existing caches and
causes the system to update all necessary kext caches.

As per your suggestions, I tried moving kexts manually:

Screen Shot 2017-08-10 at 11.12.10 PM.png


After rebooting in verbose mode, the logs kept cycling at:

IMG_0037.jpg


The pid kept incrementing. So it is probably changes in the WindowServer process that are causing this. Hopefully might change in the next beta.

Also, I was able to get the system to boot by moving back the kexts via recovery Terminal.
 
Last edited:
Can you use eGPU after disabling dGPU?
I was using eGPU and after disabling dGPU, it does not seem to work.
Do I have to "reenable" eGPU after disabling dGPU?
 
Can you use eGPU after disabling dGPU?
I was using eGPU and after disabling dGPU, it does not seem to work.
Do I have to "reenable" eGPU after disabling dGPU?

That’s precisely why I’m trying to disable the dGPU. On NVIDIA macs, the NVIDIA kexts interfere with the external AMD graphics.
Booting with the eGPU plugged in may help.
 
As per your suggestions, I tried moving kexts manually:

View attachment 712407

After rebooting in verbose mode, the logs kept cycling at:

View attachment 712408

The pid kept incrementing. So it is probably changes in the WindowServer process that are causing this. Hopefully might change in the next beta.

Also, I was able to get the system to boot by moving back the kexts via recovery Terminal.

It is likely not the WindowServer itself.
It looks like the system is forbidden to use the chip but still loads a kext to try and powermanagement it. A situation likely not foreseen by the engineers.
We had this problem not with Yosemite but with ElCap and later. Cf. e.g. #568
I wonder how your SIP status is.

Try with all kexts in their default place:
kextstat
These are all you have to worry about.
I do not know all of the kexts for Nivida, but have you tried to look at all those kexts starting with NV* and GeForce*, not only NVDA* ? There may be more belonging to this driver package.
(The chip in question for this thread was a AMD-6***, yet the offending kext was AMDRadeonX3000.kext)

If it is indeed very similar to the problem reported here then you should keep an eye on the GPU temps and eventually try to load the offending kext manually after boot.
 
Last edited:
It is likely not the WindowServer itself.
It looks like the system is forbidden to use the chip but still loads a kext to try and powermanagement it. A situation likely not foreseen by the engineers.
We had this problem not with Yosemite but with ElCap and later. Cf. e.g. #568
I wonder how your SIP status is.

Try with all kexts in their default place:
kextstat
These are all you have to worry about.
I do not know all of the kexts for Nivida, but have you tried to look at all those kexts starting with NV* and GeForce*, not only NVDA* ? There may be more belonging to this driver package.
(The chip in question for this thread was a AMD-6***, yet the offending kext was AMDRadeonX3000.kext)

If it is indeed very similar to the problem reported here then you should keep an eye on the GPU temps and eventually try to load the offending kext manually after boot.

SIP is disabled. A GeForce kext was being loaded, but there was no success even after removing all GeForce associated kexts as well. The script does cover these kexts.
Screen Shot 2017-08-11 at 1.35.08 AM.png


I presume there must be some other kext associated that might be causing this? Not sure which one it would be looking at kextstat. Also, NV* would include NVME kexts so that's one to avoid.

On another note, about your comment on GPU temps - on macOS Sierra I noticed that on moving the appropriate kexts and booting with gpu-power-prefs, GPU diode temps (via Macs Fan Control) stayed high (@ around 60+ C) versus around 45-50C when the kexts are loaded. Definitely a big jump in temps. With the script, I want to avoid loading the kexts so as to ensure eGPU compatibility on High Sierra. Looking at the link you shared, loading kexts is essential. What would you suggest regarding this?

PS: Can't thank you enough for taking the time to discuss this with me @MikeyN - sincerely appreciated.
 

Attachments

  • loaded_kexts.txt
    20.7 KB · Views: 239
Last edited:
SIP is disabled. A GeForce kext was being loaded, but there was no success even after removing all GeForce associated kexts as well. The script does cover these kexts.
View attachment 712441

I presume there must be some other kext associated that might be causing this? Not sure which one it would be looking at kextstat. Also, NV* would include NVME kexts so that's one to avoid.

On another note, about your comment on GPU temps - on macOS Sierra I noticed that on moving the appropriate kexts and booting with gpu-power-prefs, GPU diode temps (via Macs Fan Control) stayed high (@ around 60+ C) versus around 45-50C when the kexts are loaded. Definitely a big jump in temps. With the script, I want to avoid loading the kexts so as to ensure eGPU compatibility on High Sierra. Looking at the link you shared, loading kexts is essential. What would you suggest regarding this?

PS: Can't thank you enough for taking the time to discuss this with me @MikeyN - sincerely appreciated.

AMD video chip -> You have to use the grep command with the deviceid of your video card. Inside kext -> IOPCIMatch .

In my case: AMD Radeon 6750M - device id: 6741

System Information -> Graphics / Displays -> AMD Radeon HD 6750M -> device id: 0x6741

Open Terminal:


grep -Ril 6741 /System/Library/Extensions/

/System/Library/Extensions//AMD6000Controller.kext/Contents/Info.plist

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/Info.plist

/System/Library/Extensions//AppleKextExcludeList.kext/Contents/Info.plist


grep -Ril 6741 /DisableExtensions/

/DisableExtensions//AMDRadeonX3000.kext/Contents/Info.plist


My AMD video card uses the AMD6000Controller.kext and AMDRadeonX300.kext.

AppleGraphicsPowerManagement.kext : for all Mac computers.

AppleKextExcludeList.kext : The 6741 of this kext is not related to AMD video card.

AMDSupport.kext, AMDLegacySupport.kext, AMDFrameBuffer.kext, and AMDLegacyFrameBuffer.kext are dependencies of the AMD6000Controller.kext.


Update:

I do not know how Nvidia kexts are treated in their identification.

Maybe it's NVArch instead of Device ID.
 
Last edited:
AMD video chip -> You have to use the grep command with the deviceid of your video card. Inside kext -> IOPCIMatch .

In my case: AMD Radeon 6750M - device id: 6741

System Information -> Graphics / Displays -> AMD Radeon HD 6750M -> device id: 0x6741

Open Terminal:


grep -Ril 6741 /System/Library/Extensions/

/System/Library/Extensions//AMD6000Controller.kext/Contents/Info.plist

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/Info.plist

/System/Library/Extensions//AppleKextExcludeList.kext/Contents/Info.plist


grep -Ril 6741 /DisableExtensions/

/DisableExtensions//AMDRadeonX3000.kext/Contents/Info.plist


My AMD video card uses the AMD6000Controller.kext and AMDRadeonX300.kext.

AppleGraphicsPowerManagement.kext : for all Mac computers.

AppleKextExcludeList.kext : The 6741 of this kext is not related to AMD video card.

AMDSupport.kext, AMDLegacySupport.kext, AMDFrameBuffer.kext, and AMDLegacyFrameBuffer.kext are dependencies of the AMD6000Controller.kext.


Update:

I do not know how Nvidia kexts are treated in their identification.

Maybe it's NVArch instead of Device ID.

Thanks for the tip @nsgr. As suggested, I first checked the device ID:

Device ID.png


Which is 0fe9 here.

Running the mentioned grep command with this ID:

grep_results.png


I am not sure as to what to pursue next because I am removing that GeForce bundle when trying to disable the GPU as well. It also could be as you say in your update - that identification might not be the same as with AMD (no indication of AGPM kext referencing this ID). What's more fascinating is that the method worked on Sierra and High Sierra B4 so I am having difficulty comprehending what might be going on here. By luck maybe this same method starts working on subsequent betas - fingers crossed.
 
Dear Sir,

I do all steps at end reboot too.

on reboot it booted using intel card only & work fine.

but on restart it again start switching.

what to do?
 
Thanks for the tip @nsgr. As suggested, I first checked the device ID:

View attachment 712510

Which is 0fe9 here.

Running the mentioned grep command with this ID:

View attachment 712511

I am not sure as to what to pursue next because I am removing that GeForce bundle when trying to disable the GPU as well. It also could be as you say in your update - that identification might not be the same as with AMD (no indication of AGPM kext referencing this ID). What's more fascinating is that the method worked on Sierra and High Sierra B4 so I am having difficulty comprehending what might be going on here. By luck maybe this same method starts working on subsequent betas - fingers crossed.

I'm using El Capitan 10.11.6 (test machine), so the results of the grep command on the kexts are a bit different from the Sierra and High Sierra.

I think your NVArch is GK107M. Name: GK107M [GeForce GT 750M Mac Edition]

https://pci-ids.ucw.cz/read/PC/10de/0fe9


El Capitan kexts:

grep -Ril GK107M /System/Library/Extensions/

/System/Library/Extensions//NVDAGF100Hal.kext/Contents/MacOS/NVDAGF100Hal

/System/Library/Extensions//NVDAGK100Hal.kext/Contents/MacOS/NVDAGK100Hal

/System/Library/Extensions//NVDAResman.kext/Contents/MacOS/NVDAResman


You have to do a Sherlock Holmes job.

See which are the main kexts of your Nvidia video card. They are shown in Recovery mode or in the Mac OS installer (pencrive). Unfortunately there is no kextstat command in the above modes.

Then you have to use the ioreg command to know the main kexts. In my case AMD is the video card.

Recovery Mode:

ioreg | grep -i AMD

+-o AMD6000Controller

| | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService

| | | | | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService

| | | | | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService <class AtiAppServices

| | | | +-o AMDSupport <class AMDSupport


Boot normal:

kextlibs /System/Library/Extensions/AMD6000Controller.kext

For all architectures:

com.apple.iokit.IOPCIFamily = 2.9

com.apple.kext.AMDSupport = 1.4.2

com.apple.kpi.iokit = 15.6

com.apple.kpi.libkern = 15.6

com.apple.kpi.mach = 15.6


kextlibs /System/Library/Extensions/AMDFramebuffer.kext

For all architectures:

com.apple.iokit.IOGraphicsFamily = 2.4.1

com.apple.kext.AMDSupport = 1.4.2

com.apple.kpi.iokit = 15.6

com.apple.kpi.libkern = 15.6

com.apple.kpi.mach = 15.6


Update:

AppleGraphicsPowerManagement.kext work with board id or Model Identifier.

System Information -> Hardware -> Model Identifier: MacBookPro8,2


grep -Ril MacBookPro8,2 /System/Library/Extensions/

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/Info.plist

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/MacOS/AppleGraphicsPowerManagement

/System/Library/Extensions//IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/MacBookPro8_2.plist

/System/Library/Extensions//IOThunderboltFamily.kext/Contents/MacOS/IOThunderboltFamily

/System/Library/Extensions//IOUSBFamily.kext/Contents/MacOS/IOUSBFamily

/System/Library/Extensions//IOUSBHostFamily.kext/Contents/Info.plist

/System/Library/Extensions//IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBEHCIPCI.kext/Contents/Info.plist


ioreg -l | grep board-id

| "board-id" = <"Mac-94245XXXXXXX">


Use the Plist Editor to view the AppleGraphicsPowerManagement.kext information.

https://www.fatcatsoftware.com/plisteditpro/


Plist Pro -> AppleGraphicsPowerManagement.kext -> Info.plist -> IOKitPersonalities -> AGPM -> Machines -> Your machine

 
Last edited:
If you don't have time to read my story (which also describes some interesting technical approaches) just scroll down this thread until a "100% WORKING SOLUTION" text

Discrete AMD GPU of my 2011 MacBook Pro 8,2 has finally failed because of the reasons mentioned here ( http://logicboardmac.blogspot.ru/ ) and there ( https://www.macrumors.com/2015/02/19/2011-macbook-pro-repair-program-apple/ ) . It has been working perfectly for 6 years under quite a high load, even tried SETI@HOME mining at background! So I was confident that my MBP is not affected by bad solder / bad soldering quality and didn't want to bring it to Apple for a free repair program - partially because couldn't find the time to pause my important software projects, partially because I was afraid that Apple might give me a less reliable logic board or refuse a free repair because of the several unrelated repairs that I did manually by myself earlier to save money: changed thermal paste a few times, replaced the internal battery 2 times, replaced a keyboard with broken buttons, etc. But it finally broke down last week: laptop's screen image became distorted, it refused to boot OS X (always freezing half-way), and - Apple free repair program has already ended! I know there are affordable solutions like $50 BGA resoldering at unofficial local repair shop and that its possible to get a new replacement HD 6750M chip from AliExpress for $35 or cheaper ( http://www.aliexpress.com/item/DC-2...0028-216-0810028-BGA-Chipset/32764872143.html or https://www.aliexpress.com/item/DC-2015-New-216-0810001-216-0810001-Graphic-Chipset/32718112928.html , because don't know if this is true - https://www.rossmanngroup.com/board...0604-replace-216-0810005-gpu-with-216-0810028 ) to guarantee a successful repair, so the total price of repair would be either $50 or $50+$35=$85 - less than $100 in any case. But I don't like investing money to the old computers, so I have thought - what if there is some hack to force MBP to use integrated graphics ALL THE TIME, even while booting ? And then started to explore the possible solutions...

===

First of all, it is possible to successfully boot a MBP to OS X while still using the failed GPU, after you remove the AMD drivers by booting in command line mode (CMD+S) and entering these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot

The degree of your inconvenience while doing these steps - strongly depends on how heavily a screen's image is distorted in your case. In my case it was even more difficult because the OS X partition became a "read-only" partition (because of too many emergency shutdowns I did while desperately trying to boot OS X with a failed GPU) so I had to remove a hard drive from MacBook Pro and (using a USB to SATA 2.5" adapter taken from my portable HDD) attached it to a computer with Linux, then followed these instructions:

https://superuser.com/questions/961401/mounting-hfs-partition-on-arch-linux (1st answer) - carefully executed a number of commands, calculated a sizelimit for my parition layout, and finally ran sudo mount -t hfsplus -o force,rw,sizelimit=YOURNUMBER /dev/sdb2 /mnt to mount this HFS+ partition to /mnt directory in read-write mode. Then I performed these "1)-7)" steps you see above, and also repaired a filesystem by running sudo fsck.hfsplus -f /dev/sdb2 before unmounting a partition with sudo umount /mnt and putting a hard drive back to MBP...

===

This gave me a MBP which could boot to OS X although STILL using a broken AMD GPU: so it screen's image is very distorted (could browse the Internet but quite inconvenient to read a text), Launchpad is super laggy, and you can't switch to Integrated GPU using gfxCardStatus because: without AMD drivers (which we had to remove to successfully boot to OS X) Macbook Pro thinks its' internal screen is External Display and gfxCardStatus tells it is impossible to switch because External Display is using AMD GPU. Somewhere I found a suggestion that it is possible to rebuild a gfxCardStatus from the source code - https://github.com/codykrieger/gfxCardStatus - with removed or commented out 156-166 lines in the ./gfxCardStatus/Classes/GSProcess.m to make it to ignore the external display:

// find out if an external monitor is forcing the discrete gpu on
CGDirectDisplayID displays[8];
CGDisplayCount displayCount = 0;
if (CGGetOnlineDisplayList(8, displays, &displayCount) == noErr) {
for (int i = 0; i < displayCount; i++) {
if ( ! CGDisplayIsBuiltin(displays))
[list addObject:[NSDictionary dictionaryWithObjectsAndKeys:
Str(@"External Display"), kTaskItemName,
@"", kTaskItemPID, nil]];
}
}


So I rebuilt a gfxCardStatus using the instructions from the last reply of this issue -
https://github.com/codykrieger/gfxCardStatus/issues/229
(also had to download a MacOSX10.11.sdk from here - https://github.com/phracker/MacOSX-SDKs/releases - unpack and copy it to XCode's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk - because of the Apple's stupidity the latest XCode for El Capitan does not include SDK for El Capitan!) However, it still didn't work - gfxCardStatus only pretended that it has switched to Integrated GPU, while in reality OS X did not let it switch! Even after I edited ./gfxCardStatus/Classes/GSGPU.m file to enable the mysterious "Nuke it from orbit switching" option, it still couldn't switch...

===

Then I discovered this interesting repository - https://github.com/0xbb/gpu-switch - which is partially similar by its' source code to gfxCardStatus but also has the "Login Hooks" (install_hooks.sh) to "automate the switching process for login/logout". Sadly it didn't work for me... However, there is a very interesting gpu-switch text file right at the root of this repository, which describes the EFI variables!

https://github.com/0xbb/gpu-switch/blob/master/gpu-switch

After studying it and also reading this issue's comments - https://github.com/0xbb/gpu-switch/issues/11 - I became confident to try this solution, but found out that my MacBook Pro 2011 8,2 with OS X El Capitan 10.11.6 is in a VERY problematic situation:

1) rEFInd is not installed, and to install it - must disable SIP protection. But I cannot boot to Recovery mode (Command+Option+R) or to OS X Installation DVD/USB (hold Option), (to disable SIP), because they freeze while booting! - although I removed AMD kexts from my system, of course these recovery tools are using AMD kexts integrated to their design. Also cannot use Rootfool hack ( https://github.com/gdbinit/rootfool ) to disable SIP during runtime, because it works only at OS X version older than 10.11.4

2) Tried overheating my Macbook Pro on purpose (forcing CPU usage to 100% and putting it to a tightly closed bag) to force it to shutdown from overheating and then quickly reboot so that Integrated graphics will be enabled during the boot time - making it possible to boot to Recovery. But because of the wonderful high end thermal paste I have applied not so long ago - cannot overheat it even after waiting for a long time! At this point I thought that could either: a) remove AMD kexts from Installation media, or b) to connect MBP's hard drive to a Linux machine again and run a bunch of chmods to remove the SIP flags from the directories mentioned here ( http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really ) which could potentially make a system unbootable, or c) to try installing rEFInd to HFS+ partition directly from a Linux machine with root rights because it will bypass SIP --- but have not explored these options, although some of them might have worked...

3) Wanted to boot a Linux LiveCD to edit the EFI variables from there, but no matter what I did: tried booting straight without GRUB option modifications, tried editing GRUB boot options (with "e" key) to add nomodeset / remove quiet splash / or both in every combination , or like suggested in this article ( https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011) ) also add i915.modeset=0 radeon.modeset=0 or radeon.modeset=0 i915.modeset=1 i915.lvds_channel_mode=2 ; and then pressed Fn+F10 or Shift+Ctrl+Fn+F10 to boot with these options: but the Linux boot process always failed at different boot stages, no matter what popular user-friendly Linux distribution or what version of it I am trying: tried many releases of Ubuntu / Lubuntu / Fedora , even the old "AMD64 Mac" and "Alternate AMD64 Mac" images, but they always failed - either at the very beginning of boot process (black screen, or a black screen with a blinking or stuck _ character at the left upper corner) or failed at the very end of it - right before it is supposed to show a graphical desktop environment...

Later, totoe_84 wrote that he was able to boot Ubuntu in graphical mode using the following setup for GRUB:
  • To disable the AMD graphics card I added the following lines after set gfxpayload=keep
outb 0x728 1
outb 0x710 2
outb 0x740 2
outb 0x750 0
  • Next I added the following after quiet splash
    i915.lvds_channel_mode=2 i915.modeset=1 i915.lvds_use_ssc=0
(based on https://ubuntuforums.org/showthread.php?t=2157775 )

===

Then I remembered that there are not-mainstream Linux distributions for advanced users, which have a LiveCD without any graphical interface: you are dropped to a pure console and you are supposed to install the system along with only those graphical interfaces and software packages / groups of packages which you explicitly select. For example: Arch Linux (https://www.archlinux.org/) and Gentoo Linux (https://gentoo.org/) . Because their LiveCD does not have a graphical interface, they could be booted without a problem to a pure Linux console and there you could edit the EFI variables ! So here is a...

===
=== 100% WORKING SOLUTION
===
=== Force your MBP to ALWAYS use Intel integrated GPU (EFI variable fix)
===
=== to make it great again ! ;)
===


1) Create the Arch Linux LiveCD/LiveUSB :

You need a working computer for that and a spare CD/DVD/USB drive. Download the latest Arch Linux ISO image from this page - https://www.archlinux.org/download/ , at the time of writing it is archlinux-2017.03.01-dual.iso . Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB: use the great detailed instructions from this page, https://wiki.archlinux.org/index.php/USB_flash_installation_media

2) Boot to it: insert this CD/DVD/USB to Macbook Pro, hold Option key while booting, choose "EFI boot" (that is your bootable installation media), press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter. If everything is done correctly, you will find yourself at the Linux console!

3) Edit EFI vars: looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a "gpu-power-prefs-..." variable (where ... is UUID of this variable). If there is such a variable, its better to remove it with rm. In my case the efivarfs has been mounted by default with read/write permissions, but if you are getting the "operation not permitted" message while attempting to rm, it means that in your case efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again (credits to totoe_84 for this valuable addition) :
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/

If your screen is so distorted that it is difficult to see the letters, just start typing the rm gpu-power-pre and then press TAB key for autocompletion. In my case there were not such a EFI variable, only "gpu-active-..." and maybe somehow related "gfx-saved-config-restore-status-..." . Then I looked again at that gpu-switch text file (mentioned above, https://github.com/0xbb/gpu-switch/blob/master/gpu-switch),
and entered THESE COMMANDS:

*) chattr -i "/sys/firmware/efi/efivars/" <----- skip this command

Actually a gpu-switch script had "${sysfs_efi_vars}/${efi_gpu}" but I didnt have a "gpu-power-prefs-..." variable - so, partially by mistake, I didn't add that efi_gpu suffix and entered this incomplete path accidentally

*)
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a gpu-switch script

*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"

http://www.tecmint.com/chattr-command-examples/ - chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
...
Syntax of chattr ---> chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (+i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...
Operator
  1. + : Adds the attribute to the existing attribute of the files.
  2. : Removes the attribute to the existing attribute of the files.
  3. = : Keep the existing attributes that the files have.
This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances

*) cd /

Could not unmount efivars if you are inside this directory, so change to the root directory

*) umount /sys/firmware/efi/efivars/

Guarantees that your EFI variables are flushed to efivarfs filesystem, please unmount it safely before rebooting)

*) reboot

===> IF YOU DID EVERYTHING CORRECTLY, MOST LIKELY THAT YOUR MACBOOK PRO IS NOW USING INTEGRATED GRAPHICS WHILE BOOTING, AFTER BOOTING, AND IS WORKING GREAT AGAIN ! ;)

In the future maybe you could need to re-apply this solution if you would have to reset your PRAM / NVRAM / SMC because of some other problems, so remember this solution somewhere... Funny thing: now you can't switch to Discrete GPU even using gfxCardStatus, it is forever stuck at Integrated


I spent two working days to discover this solution, and really hope that it will work flawlessly for every MBP owner with a broken discrete GPU. Good luck!
If you don't have time to read my story (which also describes some interesting technical approaches) just scroll down this thread until a "100% WORKING SOLUTION" text

Discrete AMD GPU of my 2011 MacBook Pro 8,2 has finally failed because of the reasons mentioned here ( http://logicboardmac.blogspot.ru/ ) and there ( https://www.macrumors.com/2015/02/19/2011-macbook-pro-repair-program-apple/ ) . It has been working perfectly for 6 years under quite a high load, even tried SETI@HOME mining at background! So I was confident that my MBP is not affected by bad solder / bad soldering quality and didn't want to bring it to Apple for a free repair program - partially because couldn't find the time to pause my important software projects, partially because I was afraid that Apple might give me a less reliable logic board or refuse a free repair because of the several unrelated repairs that I did manually by myself earlier to save money: changed thermal paste a few times, replaced the internal battery 2 times, replaced a keyboard with broken buttons, etc. But it finally broke down last week: laptop's screen image became distorted, it refused to boot OS X (always freezing half-way), and - Apple free repair program has already ended! I know there are affordable solutions like $50 BGA resoldering at unofficial local repair shop and that its possible to get a new replacement HD 6750M chip from AliExpress for $35 or cheaper ( http://www.aliexpress.com/item/DC-2...0028-216-0810028-BGA-Chipset/32764872143.html or https://www.aliexpress.com/item/DC-2015-New-216-0810001-216-0810001-Graphic-Chipset/32718112928.html , because don't know if this is true - https://www.rossmanngroup.com/board...0604-replace-216-0810005-gpu-with-216-0810028 ) to guarantee a successful repair, so the total price of repair would be either $50 or $50+$35=$85 - less than $100 in any case. But I don't like investing money to the old computers, so I have thought - what if there is some hack to force MBP to use integrated graphics ALL THE TIME, even while booting ? And then started to explore the possible solutions...

===

First of all, it is possible to successfully boot a MBP to OS X while still using the failed GPU, after you remove the AMD drivers by booting in command line mode (CMD+S) and entering these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot

The degree of your inconvenience while doing these steps - strongly depends on how heavily a screen's image is distorted in your case. In my case it was even more difficult because the OS X partition became a "read-only" partition (because of too many emergency shutdowns I did while desperately trying to boot OS X with a failed GPU) so I had to remove a hard drive from MacBook Pro and (using a USB to SATA 2.5" adapter taken from my portable HDD) attached it to a computer with Linux, then followed these instructions:

https://superuser.com/questions/961401/mounting-hfs-partition-on-arch-linux (1st answer) - carefully executed a number of commands, calculated a sizelimit for my parition layout, and finally ran sudo mount -t hfsplus -o force,rw,sizelimit=YOURNUMBER /dev/sdb2 /mnt to mount this HFS+ partition to /mnt directory in read-write mode. Then I performed these "1)-7)" steps you see above, and also repaired a filesystem by running sudo fsck.hfsplus -f /dev/sdb2 before unmounting a partition with sudo umount /mnt and putting a hard drive back to MBP...

===

This gave me a MBP which could boot to OS X although STILL using a broken AMD GPU: so it screen's image is very distorted (could browse the Internet but quite inconvenient to read a text), Launchpad is super laggy, and you can't switch to Integrated GPU using gfxCardStatus because: without AMD drivers (which we had to remove to successfully boot to OS X) Macbook Pro thinks its' internal screen is External Display and gfxCardStatus tells it is impossible to switch because External Display is using AMD GPU. Somewhere I found a suggestion that it is possible to rebuild a gfxCardStatus from the source code - https://github.com/codykrieger/gfxCardStatus - with removed or commented out 156-166 lines in the ./gfxCardStatus/Classes/GSProcess.m to make it to ignore the external display:

// find out if an external monitor is forcing the discrete gpu on
CGDirectDisplayID displays[8];
CGDisplayCount displayCount = 0;
if (CGGetOnlineDisplayList(8, displays, &displayCount) == noErr) {
for (int i = 0; i < displayCount; i++) {
if ( ! CGDisplayIsBuiltin(displays))
[list addObject:[NSDictionary dictionaryWithObjectsAndKeys:
Str(@"External Display"), kTaskItemName,
@"", kTaskItemPID, nil]];
}
}


So I rebuilt a gfxCardStatus using the instructions from the last reply of this issue -
https://github.com/codykrieger/gfxCardStatus/issues/229
(also had to download a MacOSX10.11.sdk from here - https://github.com/phracker/MacOSX-SDKs/releases - unpack and copy it to XCode's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk - because of the Apple's stupidity the latest XCode for El Capitan does not include SDK for El Capitan!) However, it still didn't work - gfxCardStatus only pretended that it has switched to Integrated GPU, while in reality OS X did not let it switch! Even after I edited ./gfxCardStatus/Classes/GSGPU.m file to enable the mysterious "Nuke it from orbit switching" option, it still couldn't switch...

===

Then I discovered this interesting repository - https://github.com/0xbb/gpu-switch - which is partially similar by its' source code to gfxCardStatus but also has the "Login Hooks" (install_hooks.sh) to "automate the switching process for login/logout". Sadly it didn't work for me... However, there is a very interesting gpu-switch text file right at the root of this repository, which describes the EFI variables!

https://github.com/0xbb/gpu-switch/blob/master/gpu-switch

After studying it and also reading this issue's comments - https://github.com/0xbb/gpu-switch/issues/11 - I became confident to try this solution, but found out that my MacBook Pro 2011 8,2 with OS X El Capitan 10.11.6 is in a VERY problematic situation:

1) rEFInd is not installed, and to install it - must disable SIP protection. But I cannot boot to Recovery mode (Command+Option+R) or to OS X Installation DVD/USB (hold Option), (to disable SIP), because they freeze while booting! - although I removed AMD kexts from my system, of course these recovery tools are using AMD kexts integrated to their design. Also cannot use Rootfool hack ( https://github.com/gdbinit/rootfool ) to disable SIP during runtime, because it works only at OS X version older than 10.11.4

2) Tried overheating my Macbook Pro on purpose (forcing CPU usage to 100% and putting it to a tightly closed bag) to force it to shutdown from overheating and then quickly reboot so that Integrated graphics will be enabled during the boot time - making it possible to boot to Recovery. But because of the wonderful high end thermal paste I have applied not so long ago - cannot overheat it even after waiting for a long time! At this point I thought that could either: a) remove AMD kexts from Installation media, or b) to connect MBP's hard drive to a Linux machine again and run a bunch of chmods to remove the SIP flags from the directories mentioned here ( http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really ) which could potentially make a system unbootable, or c) to try installing rEFInd to HFS+ partition directly from a Linux machine with root rights because it will bypass SIP --- but have not explored these options, although some of them might have worked...

3) Wanted to boot a Linux LiveCD to edit the EFI variables from there, but no matter what I did: tried booting straight without GRUB option modifications, tried editing GRUB boot options (with "e" key) to add nomodeset / remove quiet splash / or both in every combination , or like suggested in this article ( https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011) ) also add i915.modeset=0 radeon.modeset=0 or radeon.modeset=0 i915.modeset=1 i915.lvds_channel_mode=2 ; and then pressed Fn+F10 or Shift+Ctrl+Fn+F10 to boot with these options: but the Linux boot process always failed at different boot stages, no matter what popular user-friendly Linux distribution or what version of it I am trying: tried many releases of Ubuntu / Lubuntu / Fedora , even the old "AMD64 Mac" and "Alternate AMD64 Mac" images, but they always failed - either at the very beginning of boot process (black screen, or a black screen with a blinking or stuck _ character at the left upper corner) or failed at the very end of it - right before it is supposed to show a graphical desktop environment...

Later, totoe_84 wrote that he was able to boot Ubuntu in graphical mode using the following setup for GRUB:
  • To disable the AMD graphics card I added the following lines after set gfxpayload=keep
outb 0x728 1
outb 0x710 2
outb 0x740 2
outb 0x750 0
  • Next I added the following after quiet splash
    i915.lvds_channel_mode=2 i915.modeset=1 i915.lvds_use_ssc=0
(based on https://ubuntuforums.org/showthread.php?t=2157775 )

===

Then I remembered that there are not-mainstream Linux distributions for advanced users, which have a LiveCD without any graphical interface: you are dropped to a pure console and you are supposed to install the system along with only those graphical interfaces and software packages / groups of packages which you explicitly select. For example: Arch Linux (https://www.archlinux.org/) and Gentoo Linux (https://gentoo.org/) . Because their LiveCD does not have a graphical interface, they could be booted without a problem to a pure Linux console and there you could edit the EFI variables ! So here is a...

===
=== 100% WORKING SOLUTION
===
=== Force your MBP to ALWAYS use Intel integrated GPU (EFI variable fix)
===
=== to make it great again ! ;)
===


1) Create the Arch Linux LiveCD/LiveUSB :

You need a working computer for that and a spare CD/DVD/USB drive. Download the latest Arch Linux ISO image from this page - https://www.archlinux.org/download/ , at the time of writing it is archlinux-2017.03.01-dual.iso . Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB: use the great detailed instructions from this page, https://wiki.archlinux.org/index.php/USB_flash_installation_media

2) Boot to it: insert this CD/DVD/USB to Macbook Pro, hold Option key while booting, choose "EFI boot" (that is your bootable installation media), press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter. If everything is done correctly, you will find yourself at the Linux console!

3) Edit EFI vars: looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a "gpu-power-prefs-..." variable (where ... is UUID of this variable). If there is such a variable, its better to remove it with rm. In my case the efivarfs has been mounted by default with read/write permissions, but if you are getting the "operation not permitted" message while attempting to rm, it means that in your case efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again (credits to totoe_84 for this valuable addition) :
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/

If your screen is so distorted that it is difficult to see the letters, just start typing the rm gpu-power-pre and then press TAB key for autocompletion. In my case there were not such a EFI variable, only "gpu-active-..." and maybe somehow related "gfx-saved-config-restore-status-..." . Then I looked again at that gpu-switch text file (mentioned above, https://github.com/0xbb/gpu-switch/blob/master/gpu-switch),
and entered THESE COMMANDS:

*) chattr -i "/sys/firmware/efi/efivars/" <----- skip this command

Actually a gpu-switch script had "${sysfs_efi_vars}/${efi_gpu}" but I didnt have a "gpu-power-prefs-..." variable - so, partially by mistake, I didn't add that efi_gpu suffix and entered this incomplete path accidentally

*)
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a gpu-switch script

*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"

http://www.tecmint.com/chattr-command-examples/ - chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
...
Syntax of chattr ---> chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (+i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...
Operator
  1. + : Adds the attribute to the existing attribute of the files.
  2. : Removes the attribute to the existing attribute of the files.
  3. = : Keep the existing attributes that the files have.
This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances

*) cd /

Could not unmount efivars if you are inside this directory, so change to the root directory

*) umount /sys/firmware/efi/efivars/

Guarantees that your EFI variables are flushed to efivarfs filesystem, please unmount it safely before rebooting)

*) reboot

===> IF YOU DID EVERYTHING CORRECTLY, MOST LIKELY THAT YOUR MACBOOK PRO IS NOW USING INTEGRATED GRAPHICS WHILE BOOTING, AFTER BOOTING, AND IS WORKING GREAT AGAIN ! ;)

In the future maybe you could need to re-apply this solution if you would have to reset your PRAM / NVRAM / SMC because of some other problems, so remember this solution somewhere... Funny thing: now you can't switch to Discrete GPU even using gfxCardStatus, it is forever stuck at Integrated


I spent two working days to discover this solution, and really hope that it will work flawlessly for every MBP owner with a broken discrete GPU. Good luck!
Hello i have an issue and stack at options when pressing *e* in order to add the "key word. nomoreset" when i do press enter the the screen blinks shows a command line that is mist likely the Linux console for 1 sec then the screen goes black. Please help
 
Last week my machine started exhibiting signs of dGPU failure (4th in 5 years). This time I decided to pre-empt a non-start condition by applying the fix in this thread.

I still run Snow Leopard so I modified the steps in post 528 by substituting AMDRadeonX3000.kext with ATIRadeonX3000.kext. I chose ATIRadeonX3000.kext after examining a kextstat dump.

I confirmed the same EFI GUID can be used in the NVRAM command by examining:

/System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleMuxControl.kext/Contents/MacOS/AppleMuxControl

To automate the loading of ATIRadeonX3000.kext, I created a script which includes the kextload command and this script is run by launchd during restarts. The launchd plist file to execute the script on boot was placed in /System/LaunchDaemons/

Prior to the fix, Macs Fan Control indicated PECI GPU temperature ranged from 60 - 70C with left fan at 2500 - 6000rpm. Now, it's 48 - 55C and 2000 - 2500rpm. I've been monitoring the machine for a few days and it seems to have settled down fine. I'll update if something goes south.

I also noticed in the Energy Saver control panel that Automatic graphics switching is now unchecked. The checkbox itself is, however, NOT disabled. I haven't checked it and rebooted to see what would happen. :p

Thanks to all thread participants for this fix. I was worried that my still servicable laptop would soon turn into a doorstop.
 
I'm using El Capitan 10.11.6 (test machine), so the results of the grep command on the kexts are a bit different from the Sierra and High Sierra.

I think your NVArch is GK107M. Name: GK107M [GeForce GT 750M Mac Edition]

https://pci-ids.ucw.cz/read/PC/10de/0fe9


El Capitan kexts:

grep -Ril GK107M /System/Library/Extensions/

/System/Library/Extensions//NVDAGF100Hal.kext/Contents/MacOS/NVDAGF100Hal

/System/Library/Extensions//NVDAGK100Hal.kext/Contents/MacOS/NVDAGK100Hal

/System/Library/Extensions//NVDAResman.kext/Contents/MacOS/NVDAResman


You have to do a Sherlock Holmes job.

See which are the main kexts of your Nvidia video card. They are shown in Recovery mode or in the Mac OS installer (pencrive). Unfortunately there is no kextstat command in the above modes.

Then you have to use the ioreg command to know the main kexts. In my case AMD is the video card.

Recovery Mode:

ioreg | grep -i AMD

+-o AMD6000Controller

| | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService

| | | | | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService

| | | | | +-o ATIFramebufferNI <class AMDFramebuffer

| | | | | +-o AMDNDRVService <class AtiAppServices

| | | | +-o AMDSupport <class AMDSupport


Boot normal:

kextlibs /System/Library/Extensions/AMD6000Controller.kext

For all architectures:

com.apple.iokit.IOPCIFamily = 2.9

com.apple.kext.AMDSupport = 1.4.2

com.apple.kpi.iokit = 15.6

com.apple.kpi.libkern = 15.6

com.apple.kpi.mach = 15.6


kextlibs /System/Library/Extensions/AMDFramebuffer.kext

For all architectures:

com.apple.iokit.IOGraphicsFamily = 2.4.1

com.apple.kext.AMDSupport = 1.4.2

com.apple.kpi.iokit = 15.6

com.apple.kpi.libkern = 15.6

com.apple.kpi.mach = 15.6


Update:

AppleGraphicsPowerManagement.kext work with board id or Model Identifier.

System Information -> Hardware -> Model Identifier: MacBookPro8,2


grep -Ril MacBookPro8,2 /System/Library/Extensions/

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/Info.plist

/System/Library/Extensions//AppleGraphicsPowerManagement.kext/Contents/MacOS/AppleGraphicsPowerManagement

/System/Library/Extensions//IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/MacBookPro8_2.plist

/System/Library/Extensions//IOThunderboltFamily.kext/Contents/MacOS/IOThunderboltFamily

/System/Library/Extensions//IOUSBFamily.kext/Contents/MacOS/IOUSBFamily

/System/Library/Extensions//IOUSBHostFamily.kext/Contents/Info.plist

/System/Library/Extensions//IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBEHCIPCI.kext/Contents/Info.plist


ioreg -l | grep board-id

| "board-id" = <"Mac-94245XXXXXXX">


Use the Plist Editor to view the AppleGraphicsPowerManagement.kext information.

https://www.fatcatsoftware.com/plisteditpro/


Plist Pro -> AppleGraphicsPowerManagement.kext -> Info.plist -> IOKitPersonalities -> AGPM -> Machines -> Your machine

A LOT to take in here. Viewing the I/O Registry showed a few NVDA associated kexts. The outputs are attached. I believe I am indeed covering the necessary kexts that should be removed (and if you have the time to look at the ioreg outs and check if I'm missing something I'll be glad ;p).

Coming to your update regarding AGPM - this is quite interesting. This essentially stores device graphics configs on a board ID/device identifier basis. For my Mac (via board ID) - I saw GFX0 and IGPU - a typical discrete setup on Mac. I assume you wanted me to modify this to resolve to gIOScreenLockState issue on boot?

In any case, I backed up the kext, then modified the kext to remove the GFX0 entry. In this state, the OS booted fine but as expected GPU diode temps were higher. Finally, I updated the nvram gpu-power-prefs (as done before) and removed the appropriate Nvidia and GeForce kexts. Sadly, no luck - stuck at the same state gIOScreenLock 3.

Perhaps more deeper and effective modifications could be possible with AppleGraphicsControl.kext that itself has multiple plugins, notably AppleMuxControl and AppleGraphicsDevicePolicy. But they are probably beyond my very limited knowledge of kexts and kernel functionality.
[doublepost=1502493771][/doublepost]
I confirmed the same EFI GUID can be used in the NVRAM command by examining:

/System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleMuxControl.kext/Contents/MacOS/AppleMuxControl

Quick question: How exactly did you examine that executable? Would love to look into it as well.
 

Attachments

  • ioreg.txt
    85.1 KB · Views: 268
  • ioreg_nvda.txt
    1.3 KB · Views: 182
Works for me in High Sierra for the AMD solution of this thread. Boots exactly as desired. And nvram stays across reboots.
How much time did you allow for your invoke_kext_caching() subroutine when applying your script?
Not letting this finish properly hosed two installs here. At least for now High Sierra seems to be even less robust there.
According to ee6e9a1 you now use the kextcache command manually/via the script.
That plainly destroyed my installs here. Whether from High Sierra or from Sierra for High Sierra.
On the other hand only issuing touch /System/Library/Extensions and waiting worked.

I'm running 10.12.6 on a 2011 MBP 15" 2.0Ghz. The fix worked for a single boot then went back after reboot. I followed the exact instructions from the original post. What do I need to do to make it work after restarting. Is there a step by step guide on what to do different?
 
Quick question: How exactly did you examine that executable? Would love to look into it as well.
In Finder you can navigate to:

/System/Library/Extensions/AppleGraphicsControl.kext.

Right-click the file and choose Show Package Contents. That will pop up another window from which you can drill down to:

Contents/Plugins/AppleMuxControl.kext.

Again perform Show Package Contents on that file and drill down to:

Contents/MacOS/AppleMuxControl.

Right-click this file and choose Open With >> TextEdit. Perform a search on the string, gpu-power-prefs. There will be two instances, both preceded by the familiar EFI GUID.

Please note the above pathnames are for Snow Leopard. I don't know if they apply to Sierra.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.