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?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MBP 1,1-10,2 Force 2011 MacBook Pro 8,2 with failed AMD GPU to ALWAYS use Intel integrated GPU (EFI variable fix)
- Thread starter AppleMacFinder
- WikiPost WikiPost
- Start date
-
- Tags
- a1286 amd black screen blue and black screen discrete graphics dmg dmg files gfxcardstatus glitching gpu failure gpu panic gpu switch graphic card hardware fault hardware issue logic board failure macbook pro "15 2011 macbook pro (15-inch early 2011) macbook pro 2011 radeongate restart loop white screen
- Sort by reaction score
- Status
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.
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.
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!
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:
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).
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:
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:
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!!!
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.
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>
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>
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?
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:
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:
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?
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?
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).
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:
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:
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
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
It would be interesting to know what this variable does with this GUID and the values.
79941ECD-ED36-49D0-8124-E4C31AC75CD4:AmdAcpiVar
https://github.com/erikberglund/App...fined/79941ECD-ED36-49D0-8124-E4C31AC75CD4.md
https://applelife.ru/threads/chernyj-ehkran-radeona.1718054/page-4
https://s3-eu-west-1.amazonaws.com/...1/246039_7009b138046b29929059b83b8db3cfd1.txt
https://bbs.archlinux.org/viewtopic.php?id=197260
79941ECD-ED36-49D0-8124-E4C31AC75CD4:AmdAcpiVar
https://github.com/erikberglund/App...fined/79941ECD-ED36-49D0-8124-E4C31AC75CD4.md
https://applelife.ru/threads/chernyj-ehkran-radeona.1718054/page-4
https://s3-eu-west-1.amazonaws.com/...1/246039_7009b138046b29929059b83b8db3cfd1.txt
https://bbs.archlinux.org/viewtopic.php?id=197260
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.
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.
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
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
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...
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: