nonlen

macrumors newbie
Mar 29, 2014
25
0
fsck -fy checks the integrity of the files system. I did in just in case especially if the system had been shutting down abruptly because of the graphics problem fsck -fy will correct any errors on the OS.

Yes you can use a normal user with admin privileges to remove kext from an external OS installation. In my case I did it the other way, booted the system with an external drive <opt> on boot and then choose to boot from the external drive, already without the kext, and then use the external system to find and remove the kext from the internal drive. Hope that makes sense to you.

I would use the same method for upgrading in the future, if you have access to an external drive with an installation of OS. Boot from the external OS and then use it to upgrade the internal disk and then use it again to remove the kext. This way you don't have reapply the hack.
OK, thanks Sergio. This makes sense. Did you disable SIP before the hack? Or is there anything else that should be done, other than you listed, before or after the hack?
 

MikeyN

macrumors regular
Jul 26, 2017
129
74
Alas, these tend to be a bit outdated. Available settings should be up to date in man pmset. Alas, these are also somewhat shady.

The prime example for that is the seemingly relevant to this thread setting gpuswitch. That it now does not work for us anymore might be unsurprising. What surprised me is that changes to this setting are not reflected in System Preferences, where the checkbox is still selectable.
But that it is not in the manpage is disturbing. pmset -g does not list the variable destroyfvkeyonstandby, yet the manpage does.
The settings available should be all listed with either pmset -g or within the manpage. In both cases the lists are incomplete.

But with our hack in place, I notice that there are some things left wanting. And some pmset value or combination might indeed be beneficial.

Yosemite has trouble waking up; for me: always.
Yosemite has trouble shutting down; it is very slow, apparently sometimes really hanging.
El Capitan has now reports to the same effect.
Sierra shuts down quickly, wakes up as designed. Well, most of the time.
Longer sleeping sometimes results in the same dark screen hang on waking. (10% of all tries, seems duration related, can't be sure yet.)
This only talks about 'sleeping' since hibernate immediately didn't give any differing results.

That looks to me as if the "standby" feature kicked in during the sleep period. Despite that this feature is not supported on this hardware!

Experimenting with the settings for pmset, I got unsatisfactory results so far for using the default values as well as setting standbydelay and standby to 0.

Any further ideas or findings?

Ok so I followed the guide on page one and everything seems to be working fine, should I do anything else? Thanks everyone
That sounds you are in the same situation: #836.
 

SergioF

macrumors newbie
Aug 25, 2017
7
2
Algoz, Portugal
OK, thanks Sergio. This makes sense. Did you disable SIP before the hack? Or is there anything else that should be done, other than you listed, before or after the hack?
No need to disable SIP for the hack to work. If you use the external drive solution to remove the kext then that is all that is needed.
Since my last post I have upgraded one of the MBP from Yosemite to Sierra using an external disk but after the upgrade you need to use the external disk again to remove the kext. The same goes when you do system updates for Sierra, it will re-install the offending kext which you have to remove it so that the system can boot up. The NVRAM hack wasn't affected during the upgrade or the update.
 

saldin

macrumors member
Jul 30, 2012
63
15
A friend had a Late-2011 MBP running Yosi (mine is an Early-2011) which has a garbled screen of horizontal red lines. He brought it to my house and I applied the hack for him and the screen is readable once again. The horizontal lines disappeared as if by magic!

Thank you to all the wonderful people who have contributed so much! I've thanked MikeyN plenty, but I effusively thank AppleMacFinder and nsgr as well for having researched the original solution and improving on it! I'm truly sorry if I'm missing contributors; I haven't thoroughly read every post, but I thank you all!
 
Last edited:
  • Like
Reactions: AppleMacFinder

Schmye Bubbula

macrumors member
Jul 24, 2009
40
1
Early-2011 15" MacBook Pro, ElCap.
Took a week to read this whole thread.
All methods have worked for me; I move the AMDRadeonX3000.kext, but I suffer the sleep & shutdown problems.
I have this AppleScript applet set as a login item:
<code>
do shell script "kextload /AMD_kexts/AMDRadeonX3000.kext" password "[my system password insecurely in cleartext]" with administrator privileges
</code>
I was getting ready to install SleepWatcher 2.2 to automate doing a kextunload upon every sleep, but doing it in Terminal beforehand to test always gave me a kernel panic. I don't recall this being mentioned before here, so can anyone confirm? Any other thoughts on dealing with the sleep/reboot hangs? Higher temp vs. no sleep & shutdown woes tradeoff is untenable for my situation (I'm not the only user of this Mac, and others won't understand).
 
Last edited:

MikeyN

macrumors regular
Jul 26, 2017
129
74
Early-2011 15" MacBook Pro, ElCap.
Took a week to read this whole thread.
All methods have worked for me; I move the AMDRadeonX3000.kext, but I suffer the sleep & shutdown problems.
I have this AppleScript applet set as a login item:
<code>
do shell script "kextload /AMD_kexts/AMDRadeonX3000.kext" password [my system password insecurely in cleartext] with administrator privileges
</code>
I was getting ready to install SleepWatcher 2.2 to automate doing a kextunload upon every sleep, but doing it in Terminal beforehand to test always gave me a kernel panic. I don't recall this being mentioned before here, so can anyone confirm? Any other thoughts on dealing with the sleep/reboot hangs? Higher temp vs. no sleep & shutdown woes tradeoff is untenable for my situation (I'm not the only user of this Mac, and others won't understand).
Neat AppleScript solution. Although a bit less ideal security wise, as you noted. Nevertheless: inventive new finding. If the security concerns you, take a look at the system-LaunchAgent and LoginHook solutions as well.

As I just noted a few posts above: I saw the exact wake-from-sleep issues on Yosi – always – and now there are several reports here indicating that ElCap also might have problems. But this seems somehow inconsistent. Others on ElCap seem to live a trouble free life with this hack applied. I wonder were the culprit for this lies?

However, I also saw and reported (several pages back) that kextunload for X3000 drives an immediate kernel-panic, on all OS versions. I tried several options to the command or unloading even more kexts I thought related, to save kextd the headaches it seems to get from this. No success. So far.

I didn't know about SleepWatcher. Thanks for mentioning this. That may help in automating tests for this nuisance.

For me, the only solution, 'partly perfect', was to ditch Yosi and go to Sierra. Very reluctantly. But after testing Sierra's behaviour for waking – with the kext loaded after a delay – I concluded it was worth it for getting waking back.
Unfortunately it works not 100% perfect. The last several days it worked for any amount of time sleeping. And just this night it went bonkers again. Black screen from wake, forced reboot.
Waking on Sierra seems to have a success rate close to 95% for me. (Just to throw in an unscientific number.)

So, if Sierra might be an option:
get another drive/partition and make a "clean install" of first ElCap, test this for waking issues, then make a clean install of Sierra, test that for waking issues. Then decide and follow that decision. I mention both, since somehow I am pondering the possibility that it might improve on fresh and clean installations.
And please report your findings here.
 
Last edited:
  • Like
Reactions: Schmye Bubbula

saldin

macrumors member
Jul 30, 2012
63
15
Early-2011 15" MacBook Pro, ElCap.
I have this AppleScript applet set as a login item:
<code>
do shell script "kextload /AMD_kexts/AMDRadeonX3000.kext" password [my system password insecurely in cleartext] with administrator privileges
</code>
Excellent solution! I created an app from the script, set it as a login item with the hidden check on, and it works, but asks for my password on every boot because "it needs permission to make changes". Did I make a mistake or is that the expected behavior?

Thanks!!!
 

MikeyN

macrumors regular
Jul 26, 2017
129
74
Excellent solution! I created an app from the script, set it as a login item with the hidden check on, and it works, but asks for my password on every boot because "it needs permission to make changes". Did I make a mistake or is that the expected behavior?
Why not try this pw-less solution from #599 (adapt the paths to your settings):

Update 2:
$ sudo mkdir -p /Library/LoginHook
$ sudo nano /Library/LoginHook/LoadX3000.sh


contents:
#!/bin/bash
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
exit 0


$ sudo chmod a+x /Library/LoginHook/LoadX3000.sh
$ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh



If you still really need to go the app route you might have to set the binary to run as root. Since if it isn't, then what you saw is expected behaviour. LoginHooks are executed as root automatically.
 

Schmye Bubbula

macrumors member
Jul 24, 2009
40
1
MikeyN, for me, the question of what happens coming out of sleep doesn't arise: my hang occurs when invoking sleep. (And when invoking reboot or shutdown.)

saldin,
I don't get another prompt for my system password (were you putting your password within quotation marks?—it needs to be... I've edited my earlier post #855 thusly), but you could try this instead:
<code>
do shell script "echo yourSystemPasswordInsecurelyInCleartext | sudo -S sh -c \"kextload /AMD_kexts/AMDRadeonX3000.kext\" "
</code>

Excellent solution! I created an app from the script, set it as a login item with the hidden check on, and it works, but asks for my password on every boot because "it needs permission to make changes". Did I make a mistake or is that the expected behavior?

Thanks!!!
 

nonlen

macrumors newbie
Mar 29, 2014
25
0
I have now tried this hack with 2 different MBP 8,3 and both times the hack worked.

Both MBP would not boot and showed vertical coloured stripes against the grey screen. These are the steps I used:
1. Created the Arch Linux LiveUSB as per instructions on first page. This enabled me to see that the gpu-power-prefs variable was present in /sys/firmware/efi/efivars. (optional step)
2. Removed the gpu-power-prefs variable and also all other gpu vars from /sys/firmware/efi/efivars by doing a
SMC/PRAM/NVRAM reset:
hold <leftShift><Ctrl><Opt><Power> for two seconds, release at the same time.
And then with machine still powered down.
Hold <Cmd><Opt><p><r> while powering on and wait until you hear the startup chime two times.
NVRAM is now at factory settings.
3. Booted to single user mode <Cmd><s> on boot. Did a fsck -fy first and then as per MikeyN instructions issued the following commands:
nvram boot-args="-v"
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
reboot

4. I then removed the AMDRadeonX3000.kext from the Mac OS installation by booting from an external HD with Sierra installation that already had no AMDRadeonX3000.kext. Load external HD with Sierra (minus AMDRadeonX3000.kext) and then search for the AMDRadeonX3000.kext within the internal disk /System/Library/Extensions and delete the offending kext. Without removing the AMDRadeonX3000.kext I found that on the first MBP (Sierra) the hack worked only on first boot the problem re-occurred and I had to do the hack again and on the 2nd MBP (Yosemite) it didn't boot at all.
Hi, I tried to do this and didn't succeed. I did #2, #3 as described above. I tried to boot from an external drive (El Capitan, AMDRadeonX3000.kext removed) but for some reason it didn't boot to OS X but went to, "my guess??? single user mode???? Sorry, I'm totally new with these....So I removed the AMDRadeonX3000.kext by removing HD from MBP and connecting it to an other mac. Then installed HD back to my MBP, tried to boot but again, no success and white screen. Well, then I did
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
reboot

and managed to open MBP again but still can't shut it down and boot. Should I try some other approach? Or try this again? Any thoughts?
 

nsgr

macrumors 6502
May 22, 2017
317
115
Alas, these tend to be a bit outdated. Available settings should be up to date in man pmset. Alas, these are also somewhat shady.

The prime example for that is the seemingly relevant to this thread setting gpuswitch. That it now does not work for us anymore might be unsurprising. What surprised me is that changes to this setting are not reflected in System Preferences, where the checkbox is still selectable.
But that it is not in the manpage is disturbing. pmset -g does not list the variable destroyfvkeyonstandby, yet the manpage does.
The settings available should be all listed with either pmset -g or within the manpage. In both cases the lists are incomplete.

But with our hack in place, I notice that there are some things left wanting. And some pmset value or combination might indeed be beneficial.

Yosemite has trouble waking up; for me: always.
Yosemite has trouble shutting down; it is very slow, apparently sometimes really hanging.
El Capitan has now reports to the same effect.
Sierra shuts down quickly, wakes up as designed. Well, most of the time.
Longer sleeping sometimes results in the same dark screen hang on waking. (10% of all tries, seems duration related, can't be sure yet.)
This only talks about 'sleeping' since hibernate immediately didn't give any differing results.

That looks to me as if the "standby" feature kicked in during the sleep period. Despite that this feature is not supported on this hardware!

Experimenting with the settings for pmset, I got unsatisfactory results so far for using the default values as well as setting standbydelay and standby to 0.

Any further ideas or findings?


That sounds you are in the same situation: #836.
Unfortunately Apple's manuals are not very complete. Examples are hidden boot-args (agc, agclog, etc). That is why there are several links (pmset).

The kextunload manual has other options that do not fully unload the kext. Tests, tests and more tests.

The kextunload manual also says to use kextlog (boot-args) to have a more complete report on load and unload kexts.


man kextunload

man kext_logging



Kernel Panic:

sudo kextunload /DisableExtensions/AMDRadeonX3000.kext

or

sudo kextunload /System/Library/Extensions/AMD6000Controller.kext


If the person does a lot of testing, then I recommend installing the Mac OS system on a USB stick. And open the Macbook Pro and disconnect the Hard Disk or SSD (SATA connector).

I lose a hard disk after many kernel panics and force shutdown (press button power).

It is better to lose a pen drive than it costs cheap than to lose a Hard Disk or SSD that costs more. Or use an old hard disk or SSD that you were not using.

After this episode (Lose the hard disk) I finally entered the world of SSDs.

Example:

Install & Run macOS Sierra on External SSD or USB Flash Drive

 
Last edited:

MikeyN

macrumors regular
Jul 26, 2017
129
74
Unfortunately Apple's manuals are not very complete. Examples are hidden boot-args (agc, agclog, etc). That is why there are several links (pmset).

The kextunload manual has other options that do not fully unload the kext. Tests, tests and more tests.

The kextunload manual also says to use kextlog (boot-args) to have a more complete report on load and unload kexts.


man kextunload

man kext_logging



Kernel Panic:

sudo kextunload /DisableExtensions/AMDRadeonX3000.kext

or

sudo kextunload /System/Library/Extensions/AMD6000Controller.kext


If the person does a lot of testing, then I recommend installing the Mac OS system on a USB stick. And open the Macbook Pro and disconnect the Hard Disk or SSD (SATA connector).

I lose a hard disk after many kernel panics and force shutdown (press button power).

It is better to lose a pen drive than it costs cheap than to lose a Hard Disk or SSD that costs more. Or use an old hard disk or SSD that you were not using.

After this episode (Lose the hard disk) I finally entered the world of SSDs.

Example:

Install & Run macOS Sierra on External SSD or USB Flash Drive
Excellent advice.
And that's what I did up to now, but without disconnecting the internal drive. Although I would really prefer to have a bootable Thunderbolt drive to do that external booting thing. Sadly, on TB all external disks go through a hub and that prevents booting with TB-speed. When I did get all those KPs HFSplus CoreStorage recovered quite robustly. Have you forced yours to plain HFSplus? But I also got really belt and suspenders there and fscked regularly.

Most panics were so immediate that no log survived on disk. There was then only the occasional NVRAM-litter.
 
Last edited:

mikecwest

macrumors 65816
Jul 7, 2013
1,035
391
It seems that I have to at least once a day, run the "nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00" command again.

Is it possible to add this to my boot-args, so that it just happens, EVERYTIME I boot/reboot?
[doublepost=1504199883][/doublepost]It seems I have to do this at least once daily, it is possible to have " nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 " as part of the boot-args?
 

nsgr

macrumors 6502
May 22, 2017
317
115
Excellent advice.
And that's what I did up to now, but without disconnecting the internal drive. Although I would really prefer to have a bootable Thunderbolt drive to do that external booting thing. Sadly, on TB all external disks go through a hub and that prevents booting with TB-speed. When I did get all those KPs HFSplus CoreStorage recovered quite robustly. Have you forced yours to plain HFSplus? But I also got really belt and suspenders there and fscked regularly.

Most panics were so immediate that no log survived on disk. There was then only the occasional NVRAM-litter.
When I have a kernel panic, then I enter the boot single user and do the fsck -fy and then mount -uw / to see if it has orphan files. Then reboot to enter normal boot.


DiskUtility:

Pendrive format: OS X Estend Journaled - HFSplus

Pendrive Scheme: GUID Partition Map
[doublepost=1504209192][/doublepost]
It seems that I have to at least once a day, run the "nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00" command again.

Is it possible to add this to my boot-args, so that it just happens, EVERYTIME I boot/reboot?
[doublepost=1504199883][/doublepost]It seems I have to do this at least once daily, it is possible to have " nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 " as part of the boot-args?
User Savroula post #594:

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


https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-24#post-24861561



The variables gpu-policy and gpu-active stand outside the boot-args. I think the variable gpu-power-prefs is also out of boot-args.

The boot-args are connected to the Mac OS operating system. The gpu-power-prefs must run before normal boot or before the filevault screen boot (boot encrypted).

I did a test with the variable gpu-policy and then I saw with ArchLinux that there were two gpu-policy variables but with different GUIDs.

My test with gpu-active

1 - sudo nvram FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-active=%01%00%00%00

2 - sudo nvram gpu-active=%01%00%00%00

3 - Enter ArchLinux and view /sys/firmware/efi/efivars with ls command - result:

gpu-active-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

gpu-active-7c436110-ab2a-4bbb-a880-fe41995c9f82


Update:

https://github.com/erikberglund/AppleNVRAM

https://github.com/erikberglund/App...fined/FA4CE28D-B62F-4C99-9CC3-6815686E30F9.md

https://github.com/erikberglund/AppleNVRAM/blob/master/Apple/7C436110-AB2A-4BBB-A880-FE41995C9F82.md
 
Last edited:

mikecwest

macrumors 65816
Jul 7, 2013
1,035
391
When I have a kernel panic, then I enter the boot single user and do the fsck -fy and then mount -uw / to see if it has orphan files. Then reboot to enter normal boot.


DiskUtility:

Pendrive format: OS X Estend Journaled - HFSplus

Pendrive Scheme: GUID Partition Map
[doublepost=1504209192][/doublepost]

User Savroula post #594:

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


https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-24#post-24861561



The variables gpu-policy and gpu-active stand outside the boot-args. I think the variable gpu-power-prefs is also out of boot-args.

The boot-args are connected to the Mac OS operating system. The gpu-power-prefs must run before normal boot or before the filevault screen boot (boot encrypted).

Thanks....so I just have to do it every time it messes up? I have it set with a bash file, so it’s a bit easier than typing out all of it.
 

nsgr

macrumors 6502
May 22, 2017
317
115
Thanks....so I just have to do it every time it messes up? I have it set with a bash file, so it’s a bit easier than typing out all of it.
When you use nvram with variable gpu-power-prefs, then this variable is stored in the EFI partition.

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

or

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

Test these two nvram gpu-power-prefs together and see if it resists reboot and shutdown.


Update:

0 - Boot Single User (Command + S)

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

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

3 - reboot

4 - normal boot -> login graphical interface -> reboot with Terminal -> sudo shutdown -r now

or

normal boot -> login graphical interface -> poweroff with Terminal -> sudo shutdown -h now

5 - View if resist gpu-power-prefs


Update 2:

Yes, bash file is easier and faster.
 
Last edited:

nsgr

macrumors 6502
May 22, 2017
317
115
Update 3:

1 - Boot ArchLinux and delete gpu-power-prefs-fa4ce... and gpu-power-prefs-7c436...

2 - Reboot

3 - Reset NVRAM (Command + Option + R + P)

4 - Boot Mac OS in Single User Mode (Command + S) with red screen and white stripes

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

6 - Reboot -> after reboot remain red screen and white stripes

7 - Boot ArchLinux and view gpu-power-prefs + GUID with red screen and white stripes. ls command in /sys/firmware/efi/efivars result:

gpu-power-prefs-7c436110-ab2a-4bbb-a880-fe41995c9f82

8 - Reboot

9 - Boot Mac OS in Single User Mode (Command + S) with red screen and white stripes

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

11 - Reboot

12 - Now the Screen is normal (no red screen no white stripes)

13 - Boot ArchLinux and view /sys/firmware/efi/efivar with ls command:

gpu-power-prefs-7c436110-ab2a-4bbb-a880-fe41995c9f82

gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
 

pheimbach

macrumors newbie
Sep 1, 2017
3
0
I want to thank all the contributors of this thread. My early 2011 15" Macbook pro work fine now.
I don't have the "sleep" problem. My mac always comes back without a problem. I'm running Sierra 10.12.6
I have noticed that my Mac's battery life is completely screwed up now. As if it was running on the AMD.
I normally got around 7 hours of battery life. Now I hardly get 2,5 hours; like it used to do when running on the AMD.
Has anyone experienced this too?
Thanks.
 

rlebleu

macrumors member
Jul 1, 2017
52
4
Are you loading AMDRadeonX3000.kext after logging in? In my case, battery draw dropped by at least 30%, and temperature dropped 20c.

That file was removed (relocated) from the extensions folder to prevent it being loaded at boot time. After you have logged in, it should be reloaded...

sudo kextload /Wherever you moved it to from the extensions folder/AMDRadeonX3000.kext
 

pheimbach

macrumors newbie
Sep 1, 2017
3
0
Really? Does that mean I have to remove it again before reboot/shutdown? And do I have to disable SIP again?
 

rlebleu

macrumors member
Jul 1, 2017
52
4
Really? Does that mean I have to remove it again before reboot/shutdown? And do I have to disable SIP again?
No need to remove it or move it. Initial steps of this fix required you to move it from the extensions folder to another folder... when I did it I moved to AMD_Kexts. If you reboot, you will have to reload again - yes. In my case, I very seldom reboot. I just close the lid, and it goes into safe sleep. Open the lid and carry on from where were...
 

pheimbach

macrumors newbie
Sep 1, 2017
3
0
Okay. I will try that. Thanks! :)
Do you have to remove the kext when you reboot?
 
Last edited:

nonlen

macrumors newbie
Mar 29, 2014
25
0
There seems to be too many alternative ways of trying to fix this...I believe there are many of us "inexperienced" MBP 2011 users who would really appreciate if someone could write the list of the whole procedure from A to Y that includes everything that needs to be done. At this moment, at least for me, there are too many guidelines to follow....
 

MikeyN

macrumors regular
Jul 26, 2017
129
74
There seems to be too many alternative ways of trying to fix this...I believe there are many of us "inexperienced" MBP 2011 users who would really appreciate if someone could write the list of the whole procedure from A to Y that includes everything that needs to be done. At this moment, at least for me, there are too many guidelines to follow....
There is not *one* guide to write up. Many roads lead to Rome. The best option would be if AppleMacFinder would update the first post of this thread pointing to the best alternatives.

Anyway. Even if this post now will quickly drown in the sheer length of this thread, I think this is currently one of the better guides:

#####__ The Guide __#####

This guide assumes that you run a stock system. Problem just occured. That means:
This guide assumes that all kexts are still in their default location /System/Library/Extensions.
Having all AMD-kexts there except one is beneficial for 'proper' operation.

To get some display acceleration back it will be necessary to force the machine to not boot into discrete graphics (dGPU) but directly into integrated graphics (iGPU). This will give you back your laptop – but you will lose some features: e.g. the ability to drive an external display. Thunderbolt data connections should work.

The initial procedure:

– To start from a clean slate: reset SMC and PRAM/NVRAM:

shutdown, unplug everything except power, now hold

<leftShift>+<Ctrl>+<Opt>+<Power>

release at the same time;

– Now power on again and hold

<Cmd>+<Opt>+<p>+<r>

at the same time until you hear the startup chime two times.

– Boot into Recovery by holding

<Cmd>+<r>+<s>

– Disable SIP:

csrutil disable

– disable dGPU on boot

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

– enable verbose boot mode:

nvram boot-args="-v"

– reboot into single user-mode by holding

<Cmd>+<s>

on boot

– mount root partition writeable

/sbin/mount -uw /

– make a kext-backup directory

mkdir -p /System/Library/Extensions-off

– only move ONE offending kext out of the way:

mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/

– let the system update its kextcache:

touch /System/Library/Extensions/

– wait for the kextcache process to finish
then

reboot

Reboot normally:
you will have an accelerated iGPU display.


But the system doesn't know how to power-management the failed AMD-chip.
For that you have to either manaully load the kext after boot by:

sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext

Automate this with the following LoginHook:

sudo mkdir -p /Library/LoginHook
sudo nano /Library/LoginHook/LoadX3000.sh


with the following content:

#!/bin/bash
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
exit 0


then make it executable and active:

sudo chmod a+x /Library/LoginHook/LoadX3000.sh
sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh


Preventive measures for future use

There are two further caveats to know: This is reversible when the SMC/PRAM/NVRAM is reset. If that happens the GPU-power-pref nvram can/has to be set again to force the use of the iGPU from boot-time.

Since this can happen quite easily (and is often erroneously recommended way too many times than it is actually useful), you should probably prepare for such a scenario and create a simple script to greatly speed up the process and also make entering the necessary variable much less error prone:

sudo nano /force-iGPU-boot.sh

– Enter the following content to this file:

#/bin/sh
sudo nvram boot-args="-v"
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
exit 0


– Now make that executable:

sudo chmod a+x /force-iGPU-boot.sh

In the future, when the SMC/PRAM/NVRAM gets reset to default values it is now possible to boot into SingleUser with:

<Cmd>+<s>

– And after mounting your boot-volume read-write to execute just:

sh /force-iGPU-boot.sh

This setup has now one kext in a place Apple's installers do not expect. That is why in this guide SIP has not been reenabled. If an update that contains changes to the AMD drivers is about to take place it is advisable to move back the AMDRadeonX3000.kext to its default location before the update process. Otherwise the updater writes at least another kext of a different version to its default location or at worst you end up with an undefined state of partially non-matching drivers.

After any system update the folder /System/Library/Extensions has to be checked for the offending kext. Its presence there will lead to e.g. a boot hang on Yosemite and Sierra, an overheating boot-loop in High Sierra.

Further: this laptop is overheating, no matter what you do. The cooling system is inadequate and the huge number of failing AMD chips are just proof of that.

To prolong the life of this now hacked machine it is advisable to abstain from really heavy lifting over prolonged stretches of time. Strictly follow the usual recommendations for laptops: use on hard surfaces, keep the fans and fins inside it clean. Using any fancontrol software with relatively aggressive settings should also help: like smcFanControl, MacsFanControl, or TGPro (the latter both commercial).


This is fairly complete and what I do recommend to everyone asking me.
Nevertheless. We're not done here, yet. Improvements are welcome. Share them!
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.