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.

fg74

macrumors newbie
Dec 15, 2017
1
0
Found a solution :)

It's not necessary to remove all AMD*.* folders. I only removed some folders and the F1/F2 works..
I also discovered that I had problems with Sleep mode, this is also solved now.

The folders I did remove:

AMDRadeonX3000.kext
AMDRadeonX4000.kext
AMDRadeonX4100.kext
AMDRadeonX4150.kext
AMDRadeonX4200.kext
AMDRadeonX4250.kext
AMDRadeonX5000.kext
AMDRadeonX5000HWServices.kext

Brian

Various OS updates seem to reset the extensions, and the list of *.kext files might change. Can you say how one might know more generally which are the right kext files to remove? (e.g., in 10.13.2 there are other AMDRadeonX*.kext files beyond those you list here). Thanks. -George
 

xanderx007

macrumors 6502
Nov 7, 2017
262
140
The GFX CardStatus fix worked for me. My question is, has anyone found a way to use an external display with this fix (or any other fix)?

Thanks!


https://forums.macrumors.com/thread...g-intel-integrated-gpu.2071248/#post-25600818

In particular, this USB to DVI/HDMI/VGA adapter.

Screen Shot 2017-12-15 at 18.03.17.png
 
Last edited:

xanderx007

macrumors 6502
Nov 7, 2017
262
140
The "HP USB Graphics adapter", or the Wavlink adapter?

Thanks!

Wavlink (I don't know why the screen shot did not upload when I first posted). At any rate, they use the same display link driver, which means they probably use the same display link OEM hardware.
 

rcmcfe

macrumors newbie
Jul 15, 2017
16
2
Wavlink (I don't know why the screen shot did not upload when I first posted). At any rate, they use the same display link driver, which means they probably use the same display link OEM hardware.

So, just to be clear, you're macbook pro has the graphics card failure issue, and you're still able to use an external monitor using the wav link adapter?
 

2kbill

macrumors newbie
Jul 10, 2008
1
0
Thank you AppleMacFinder for your work on this fix. My early 2011's panics had made the transition from every now and then to every few minutes recently. I looked at the price of a new mbp, and ugh! plus I like my ports. You have postponed the inevitable for the time being, I am grateful!
 

nsgr

macrumors 6502
May 22, 2017
317
117
Various OS updates seem to reset the extensions, and the list of *.kext files might change. Can you say how one might know more generally which are the right kext files to remove? (e.g., in 10.13.2 there are other AMDRadeonX*.kext files beyond those you list here). Thanks. -George

If it's a Macbook Pro 2011, then it would be the AMDRadeonX3000.kext. Reports from users with Macbook Pro 2011 in this forum.

This would be the case if you had no idea which AMDRadeonX is connected to your AMD GPU.

If an update happened and the system froze because of the problematic kext, then you should enter Safe Mode (press SHIFT key at boot):

1 - After login in Safe Mode -> Apple logo -> About this Mac -> System Report -> Graphic /Displays -> select AMD Radeon GPU -> Device ID.

2 - In my case (AMD Radeon HD 6750M) -> device ID: 0x6741.

3 - Search for this device ID (6741) with the grep command in the kexts directory.
Code:
grep -iRl 6741 /System/Library/Extensions/
/System/Library/Extensions/AMD6000Controller.kext/Contents/Info.plist
/System/Library/Extensions/AMDRadeonX3000.kext/Contents/Info.plist
/System/Library/Extensions/AppleGraphicsPowerManagement.kext/Contents/Info.plist
/System/Library/Extensions/AMDLegacySupport.kext/Contents/Info.plist
/System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist

4 - For my AMD GPU, the AMDRadeonX3000.kext will always be the problematic kext.

It would only be necessary to move the AMDRadeonX3000.kext to the /DisableExtensions directory - then manually load after login or use LoginHook.
 
Last edited:

OfficialKinger

macrumors newbie
Dec 16, 2017
1
0
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=1513482640][/doublepost]Does this effect iMovie in any way?
I make YouTube videos and use iMovie to edit.
My Mac started freaking out with iMovie, then everything went to sh*t...
I paid to have it sodred and it fixed it for almost a year, but the same problem is back.
Luckily, I was able to backup my computer this time.
I’m not a pro when it comes to computers, I know enough, but not everything, so I just wanted to make sure if I did these steps it wouldn’t effect my editing in any way since it’s using integrated graphics.

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!
 

Theejonfields

macrumors newbie
Dec 17, 2017
3
0
Guys I need your help. My entire career is on my mbp and it’s gone to ****.


I went through the original method. Along the way I don’t think all of the kext files moved over. I went through the editing of EFI, created the gpu pref, rebooted. The lines were gone but it still didn’t boot. I knew it was the kext files right away. I was able to boot into recovery so I disabled SIP and moved the files from the terminal there. Once I restarted nothing happened. I went back into Linux to try and move kext files but now it says operation not permitted. I tried to remove the gpu pref to create a new one and it says operation not permitted. I did a pram reset and my screen is back to the lines. I need help guys please.
 

celensa0

macrumors newbie
Dec 17, 2017
1
0
great job, thx guys! my mbp 15 late 2011 is on high sierra, so my question on all: did anyone manage to get the brightness and wakeup working, mine does wake up, but the display stays black, hard reset only. tried all options gpuswitch 0, 1, and 2, all the same. hope this thread stays alive and up to date
 

GSTX

macrumors newbie
Dec 18, 2017
1
0
hey guys! I've followed all 'AppleMacFinder / FGuarani' tutorial and I got the video issue (stripped screen) solved :) however, I just can't load the OS (I always stuck on Apple logo / 40% loading bar); I know I need to remove the AMD Kexts, but I've tryed many times and no success :/ I just can't disable the SIP (it always give 'no command found' message, in Recovery Mode via Terminal) neither get the 'cd /Volumes/Macintosh\ HD' successed (because it always give 'no file or directory found' message, in Recovery Mode via Terminal)... I'm reading these posts and trying get this done along 4 or 5 days! I think I'm quite close to make this perfectly done! please, anyone could help me at this point? thanks everyone here for every single tip... cheers
 

lpuerto

macrumors regular
Mar 4, 2014
144
37
Europe
There is a BootFlag called darkware that is placed in nvram boot-args.

1 - Download XNU 4570.1.46
https://opensource.apple.com/release/macos-1013.html

2 - Extract xnu-4570.1.46.tar.gz file.

3 - Use grep darkwake -> directory "xnu-4570.1.46"

Example:
Code:
grep -iRn darkwake xnu-4570.1.46 | more
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:303:// gDarkWakeFlags
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:305:    kDarkWakeFlagHIDTickleEarly      = 0x01, // hid tickle before gfx suppression
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:306:    kDarkWakeFlagHIDTickleLate       = 0x02, // hid tickle after gfx suppression
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:307:    kDarkWakeFlagHIDTickleNone       = 0x03, // hid tickle is not posted
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:308:    kDarkWakeFlagHIDTickleMask       = 0x03,
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:309:    kDarkWakeFlagAlarmIsDark         = 0x0100,
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:310:    kDarkWakeFlagGraphicsPowerState1 = 0x0200,
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:311:    kDarkWakeFlagAudioNotSuppressed  = 0x0400
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:332:static uint32_t         gDarkWakeFlags = kDarkWakeFlagHIDTickleNone;
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:1051:static SYSCTL_INT(_debug, OID_AUTO, darkwake, CTLFLAG_RW, &gDarkWakeFlags, 0, "");
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:1121:    PE_parse_boot_argn("darkwake", &gDarkWakeFlags, sizeof(gDarkWakeFlags));

Reference:

https://opensource.apple.com/source/xnu/xnu-3789.51.2/iokit/Kernel/IOPMrootDomain.cpp.auto.html

https://www.reddit.com/r/hackintosh/comments/2t09fb/what_do_darkwakeno_and_darkwake010_do_for_you/

http://www.insanelymac.com/forum/to...id-wake-from-sleep-for-skylake-iris-graphics/

https://medium.com/sfbayhacker/macbook-gets-hot-with-lid-closed-12fc0e7e7016


Thanks a lot for the additional info. Right now I'm hibernating so I guess it isn't wakening up at all. Besides, Do our macs have the ability of doing that?
 

xanderx007

macrumors 6502
Nov 7, 2017
262
140
Guys I need your help. My entire career is on my mbp and it’s gone to ****.


I went through the original method. Along the way I don’t think all of the kext files moved over. I went through the editing of EFI, created the gpu pref, rebooted. The lines were gone but it still didn’t boot. I knew it was the kext files right away. I was able to boot into recovery so I disabled SIP and moved the files from the terminal there. Once I restarted nothing happened. I went back into Linux to try and move kext files but now it says operation not permitted. I tried to remove the gpu pref to create a new one and it says operation not permitted. I did a pram reset and my screen is back to the lines. I need help guys please.

hey guys! I've followed all 'AppleMacFinder / FGuarani' tutorial and I got the video issue (stripped screen) solved :) however, I just can't load the OS (I always stuck on Apple logo / 40% loading bar); I know I need to remove the AMD Kexts, but I've tryed many times and no success :/ I just can't disable the SIP (it always give 'no command found' message, in Recovery Mode via Terminal) neither get the 'cd /Volumes/Macintosh\ HD' successed (because it always give 'no file or directory found' message, in Recovery Mode via Terminal)... I'm reading these posts and trying get this done along 4 or 5 days! I think I'm quite close to make this perfectly done! please, anyone could help me at this point? thanks everyone here for every single tip... cheers

You might want to try the GRUB solution in both your cases, which were relatively similar to mine when I was on the EFI fix. Though the EFI fix works, it does so on a case to case basis, and a bit unstable. The GRUB fix is basically similar to the EFI fix, with the exception that it forces the OS to use only the iGPU at startup, ignoring the dGPU altogether.
 

mindwalkr

macrumors newbie
Dec 19, 2017
3
0
Hi Guys!

First of all, thanks a lot to all the people who have contributed one way or another to fixing our broken MacbookPros. My Macbook pro toasted the dGPU last week after several nights of converting x264 to x265 and Apple Support has told me that they cannot do anything about it, and won't even attempt to repair it at cost. For trade-in value, my poor Mac is now worth 0 Eur! (even though it's a pretty good machine with 8Gb and an SSD).
Anyhow, I have read through most of this thread but it is obviously pretty massive, but I reckon there's 3 main fixes at the moment:

1) EFI fix (AppleMacFinder's initial post)
2) Kernel Extensions fiddling fix (MikeyN, post 875 -> https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-35#post-24956091 )
3) GRUB fix (Brainshutdown's solution, mentioned in post 1033 -> https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-42#post-25255227 )

Now, so far I've tried the GRUB fix and it is working fine for me so far. (just a couple of hours in, although I haven't completed the process because in order to compile the AMDGPUWakeHandler I need the latest XCode, since the one I have with Yosemite complains that the Project file is incompatible. Now, the only thing I don't particularly like about this solution is that it shows that GRUB login screen and it seems to take slightly longer to boot into GRUB that it did before, in order to get at the shiny Apple logo of hope.

It seems to me that solution 2) seems to be the easiest to perform since it doesn't require a USB stick, but I've read somewhere on this thread that it isn't totally reliable when the laptop wakes up from sleep ?

What's the overall consensus about the 3 methods, now that everyone has experimented a bit with all of them ? Which one so far yields to more stable results ? The GRUB seems to have issues with High Sierra with backlight and sleep... is that also the case for the other methods ?

  • Totally off-topic note

    while attempting the GRUB fix, I wrote the NVRAM with that long attribute
    Code:
    fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
    and rebooted. Suddenly all symptoms of the broken GPU were gone, and I booted into MacOS straight from the HD, without GRUB installed yet. The I shut down the laptop... and after 15 minutes I turned it on again and the dGPU was again active as I had those bad horizontal lines. I thought the NVRAM attribute was supposed to stick and survive restarts ?

  • Totally off-topic note 2

    how come the GRUB solution works ? Is it only because with GRUB installed, the dGPU isn't activated at all ? Is that a peculiarity of GRUB ? Or is it something in the magic config file for GRUB ?
    Code:
    set timeout=10
    menuentry "macOS" {
       insmod hfsplus
       outb 0x728 1
       outb 0x710 2
       outb 0x740 2
       outb 0x750 0
       search --set=root --file /System/Library/CoreServices/boot.efi
       chainloader /System/Library/CoreServices/boot.efi
    }
 

xanderx007

macrumors 6502
Nov 7, 2017
262
140
Hi Guys!
Now, so far I've tried the GRUB fix and it is working fine for me so far. (just a couple of hours in, although I haven't completed the process because in order to compile the AMDGPUWakeHandler I need the latest XCode, since the one I have with Yosemite complains that the Project file is incompatible. Now, the only thing I don't particularly like about this solution is that it shows that GRUB login screen and it seems to take slightly longer to boot into GRUB that it did before, in order to get at the shiny Apple logo of hope.

Better that than an unstable Mac. Grub load times varies from system to system, in my case it takes about 10 seconds or so before the Grub screen loads.

Also, why did you need to compile AMDGPUWakeHandler? You can simply download the file @brainshutdown included on his first post on the GRUB solution thread and use it right away (as I have).

It seems to me that solution 2) seems to be the easiest to perform since it doesn't require a USB stick, but I've read somewhere on this thread that it isn't totally reliable when the laptop wakes up from sleep ?

What's the overall consensus about the 3 methods, now that everyone has experimented a bit with all of them ? Which one so far yields to more stable results ? The GRUB seems to have issues with High Sierra with backlight and sleep... is that also the case for the other methods ?

I haven't tried the Kernel fix. I went through it a few times and I found it a bit complicated since I have to code the login hook. I'm currently on the Grub fix and have been so for quite some time, and have not experienced any sleep, shutdown or restart issues. High Sierra seems to be an issue in any case, even on newer MBPs. I'm still on Yosemite, didn't bother upgrading even to Sierra since I don't see any additional benefit. I'd rather have a stable, working system than a new one.

  • Totally off-topic note

    while attempting the GRUB fix, I wrote the NVRAM with that long attribute
    Code:
    fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
    and rebooted. Suddenly all symptoms of the broken GPU were gone, and I booted into MacOS straight from the HD, without GRUB installed yet. The I shut down the laptop... and after 15 minutes I turned it on again and the dGPU was again active as I had those bad horizontal lines. I thought the NVRAM attribute was supposed to stick and survive restarts ?
No. As I understand it, the process just resets the NVRAM value, disabling the dGPU during that startup. It resets to it's default value once you restart or shutdown the MBP. That is what the grub is for; it resets the NVRAM value before the OS loads so the OS ignores the dGPU altogether.

  • Totally off-topic note 2

    how come the GRUB solution works ? Is it only because with GRUB installed, the dGPU isn't activated at all ? Is that a peculiarity of GRUB ? Or is it something in the magic config file for GRUB ?
    Code:
    set timeout=10
    menuentry "macOS" {
       insmod hfsplus
       outb 0x728 1
       outb 0x710 2
       outb 0x740 2
       outb 0x750 0
       search --set=root --file /System/Library/CoreServices/boot.efi
       chainloader /System/Library/CoreServices/boot.efi
    }
Again, as @branishutdown explained, the GRUB solution simply ignores the dGPU upon startup (by changing the boot.efi settings). It does not in any way disables it. It still consumes power, and is why it needs the AMDGPUWakeHandler to handle that sleep issue.

To disable it fully, some have resorted to disabling the resistor/transistor that supplies power to the dGPU, but for me, that's too risky a method. I have my system working well as it is.
 

neilpaolo

macrumors newbie
Dec 19, 2017
2
0
Hi Lloyd22
I have the same exact issue that you're having right now. I was able to get it to work once by overheating it; letting it cool down and powering it back. It only worked once though...
Please let me know if you're able to resurrect your MBP again...
Thanks,
Neil
 

xanderx007

macrumors 6502
Nov 7, 2017
262
140
If you guys want a better solution (in my opinion):

https://realmacmods.com

I did it on my 2011 MBP. Adam is the person to communicate with.

Everything works! He will send you data on how to do it.

The Grub solution works just as well, without having to disable the resistor (thus, no risk of any damage to the logic board). The only drawback is that the dGPU is still powered, but, I'd rather have that than risking any further damage to the machine.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.