That's kewl. But, take note, the dGPU issue does not get reported in AHT. Just monitor it for the time being.
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
That's kewl. But, take note, the dGPU issue does not get reported in AHT. Just monitor it for the time being.
Hi,
Just wanted to say a massive thank you to you AppleMacFinder your detailed solution. My wife's MacBook Pro died a couple of days ago. We were just hours away from buying a new MacBook when she came across your post. I carefully followed your instructions and within an hour I had her MacBook back up and running again.
I think it's totally disgusting that Apple haven't made more of an effort to make this fix more widely known (i.e. post this information on the page where they describe the problem). While we could have afforded to buy a new MacBook (it would have hurt, but we could do it), there are people out there that aren't in that position (e.g. students). I take on board the comments from others that it may result a fix that doesn't return 100% functionality, however the functionality it brings looks to be more than acceptable to most, and Apple could detail that in their post.
So, once again a massive thank you.
Vc
Just wanted to say a massive thank you to you AppleMacFinder your detailed solution. My wife's MacBook Pro died a couple of days ago. We were just hours away from buying a new MacBook when she came across your post. I carefully followed your instructions and within an hour I had her MacBook back up and running again.
I think it's totally disgusting that Apple haven't made more of an effort to make this fix more widely known (i.e. post this information on the page where they describe the problem). While we could have afforded to buy a new MacBook (it would have hurt, but we could do it), there are people out there that aren't in that position (e.g. students). I take on board the comments from others that it may result a fix that doesn't return 100% functionality, however the functionality it brings looks to be more than acceptable to most, and Apple could detail that in their post.
So, once again a massive thank you.
Vc
I am one of those people who can't really afford to get a new MBP at any moment, but, I believe Apple did make an effort to compensate for the failing dGPUs with the replacement program, even for those units outside the warranty period.
In my case, It took around 4 years before the dGPU failed for the first time, and I wasn't even aware of the issue till it did (which is rather common among a lot of users). I had a slight panic, but, I still have my trusty 2007 Mac Mini to do research on, and a few low-level design work, so, I wasn't worried so much. But, that's the thing, I did research.
I was able to qualify for the replacement program. This time though, it too a little over the year when the second dGPU failed September this year, well way beyond the replacement program, and there were no parts left even if I was willing to pay for it.
I'm a heavy MBP user. I'm a graphic designer by trade, and my MBP has endured much "abuse" from me, and I've even dropped it a couple of times from waist height. It was a good thing all it needed was a few nudges to the connectors, and the screen didn't shatter. The Keyboard did start to fail as early as 2 years, and it's intermittently functioning every now and then. That's why I have a backup wireless keyboard. I'm on my second Magsafe, bought only after 5 years. The cable is intact, with no sign of abuse except for the discoloration, and I only needed to replace it because the spring-loaded contacts failed completely under "normal" wear and tear. Didn't I say "abuse?"
I'm exaggerating when I said "abuse." I am careful with my MBP, enough that it wouldn't get spilled on, or have crumbs on the keyboard, or leave it with so much dust the fans fail (and they do get rather dusty). As a user, I can be neglectful at times, and that's on me.
I also live in a tropical country, and I don't have AC at home. I do have a fan to help with heat dissipation. It's a wonder that my MBP failed only after 5 years in the condition and use and abuse it went through with me.
Now, what I am saying is, when it failed the first time, I did research. I did not blame Apple. I did not curse Apple. I do not find it "disgusting" that they do not give out information on how to fix an already out-of-warranty machine, nor if they can even fix it themselves.
But, we have Apple users who are tech-savvy enough to give us those information. Sure, we could use a little more help from Apple, but, they did that (replacement program), even though it was more to get rid of their surplus motherboards, so they wouldn't go to waste.
As it is, because of research, I found out that I could still fix my MBP, and use it for a couple more years or so. I'm not depending on Apple to help me in any way; they've already done that within the warranty (I didn't get Applecare) and outside the warranty. I guess, I'm just not keen on stressing myself on things I have no control over, nor blame or curse Apple for something they had really no control over after the fact.
No, I'm not siding with Apple on this. Especially not now with the new MBPs. But, again, they wouldn't have known about those issues until they've released it to the consumers (that's what feedback is about), and with all the new "innovations" they've put, there would always be problems.
I guess, it a good thing I'm not an early adapter. Financially, even if I could afford to get stuff, I do wait a little while, maximizing my current gadget/equipment till I really need a new one. For example, both my Nokia 3210 and SE w810i lasted 10 years each, before I really needed to get an iPhone project-wise. The latest models at the time were the 6 and 6s, but I opted to get a 16GB 5s instead. That 5s is now on its 4th year.
As for the MBP, I'm really going to need one soon, especially since newer Adobe apps and my job require it. I do seminar and workshop presentations. I was able to procure a USB graphics adapter that works, and I should be able to squeeze a few more years from my MBP, unless it fails in some other aspect.
In conclusion, let's not blame Apple too much unnecessarily. I understand where you're coming from, but, let's be objective enough to know that there is a crucial balance between the available technology and how users use that technology. Right now, because of what happened, I am more diligent, keeping myself informed, as well as keeping others informed as much as I can, especially since it's already outside of Apple's per view of informing people about the problems out of warranty machines have. Again, that's why we have support communities to begin with, and the guys here have done wonderful jobs above and beyond.
It's not a popular opinion, I know.
This happened to me too when trying to apply the GRUB solution on a laptop which had it's original HDD replaced by an SSD. In this case, the grub.cfg file had to have a reference to the SSD UUID as below
Code:
search --no-floppy --fs-uuid --set=root REPLACE_WITH_YOUR_UUIDIt seems that when the HDD is not the original one, for some reason you have to specify the new UUID or else it tries to boot from something that doesn't exist and then you get the prohibited symbol (at least that was what happened to me)
[doublepost=1513952654][/doublepost]
From my experience so far, I think there's a little more to it. When you set the NVRAM variable, it should stick and survive reboots (NV stands for Non Volatile) and that's also part of the RAM you clear when you do a hardware NVRAM/PRAM reset (with CMD+OPTION+P+R on boot).
I think what happens then is that when you boot into MacOS without the GRUB loader (and therefore all Kernel Exts and dGPU fully loaded), the OS itself or some extension sets the particular NVRAM variable back to boot with the dGPU. That's why your next boot will show the corrupted screen.
However, if you boot MacOS via GRUB (disabling the GPU) right after setting the NVRAM back to integrated GPU, then the NVRAM variable won't be reverted, because whatever does it has not been loaded at all.
If you try to boot MacOs with GRUB while the screen is distorted (dGPU active on boot), then GRUB will disable the dGPU and your screen goes black because you've "switched off" the GPU that was giving you a screen at that time and it doesn't seem to switch back to integrated. That's why after you set the NVRAM variable to boot with integrated GPU boot, your next boot must be with GRUB (via USB stick if not blessed yet), otherwise the moment you go to a standard boot to MacOS, the NVRAM gets set back to boot with discrete GPU since the said GPU will be active and something will revert back the NVRAM parameter
Indeed, and the trick which ignores (or unloads from the OS) are those magic three outb statements.
UPDATE:
Same problem has come back, black screen, freeze during skype, restart not finishing, etc. So guess it's the dGPU after all :-(
She'll go back to the shop that 'repaired' it, but it may end up on my plate - hope I can count on you guys if I get stuck in the FIX write up ;-)
It was most probably a hiccup. When the dGPU fails, it does so randomly and gradually. Sometimes it works, other times it won't, until it stops working altogether.
Try the EFI fix first. It does work for some as it did for me for a time, but it's unstable later on. If that becomes problematic, then try the Grub solution.
Hey there,
First off, thank you very much for this post! My MacBook Pro died 2 years ago and then again back in October. Apple said they had no parts anymore so the laptop had been sitting in my drawer since then. I tried the LiveCD option with a USB key and it worked, at first I didn't have any of those GPU or GFX variables in the /sys/firmware/efi/efivars directory, but after using an external keyboard I was able to get the steps to work and got back into my MacBook.
It worked fine for 2 days, but I restarted the computer a few minutes ago and it's bricked again. I've tried the same process but I can't rm any of the files in that directory, even after umounting and mounting with the -t efivarfs command. Not sure what's changed, or why my system is bricked again, but I'm hoping I'm doing something wrong the second time through.
First off, thank you very much for this post! My MacBook Pro died 2 years ago and then again back in October. Apple said they had no parts anymore so the laptop had been sitting in my drawer since then. I tried the LiveCD option with a USB key and it worked, at first I didn't have any of those GPU or GFX variables in the /sys/firmware/efi/efivars directory, but after using an external keyboard I was able to get the steps to work and got back into my MacBook.
It worked fine for 2 days, but I restarted the computer a few minutes ago and it's bricked again. I've tried the same process but I can't rm any of the files in that directory, even after umounting and mounting with the -t efivarfs command. Not sure what's changed, or why my system is bricked again, but I'm hoping I'm doing something wrong the second time through.
Hi,
Thanks for the detailed solution. I followed it and successfully fix the issue but after some time I was faced with slow speed in Yosemite so I tried to reinstall it that never happened. I tried everything but now I can not even reach Comm + S prompt, the black screen. Any solution?
Thanks for the detailed solution. I followed it and successfully fix the issue but after some time I was faced with slow speed in Yosemite so I tried to reinstall it that never happened. I tried everything but now I can not even reach Comm + S prompt, the black screen. Any solution?
I do respect your opinion and normally I'd agree with much of what you've said. However my opinion (and I stress it is only my opinion) is based on the fact that:
A) Apple admitted it shipped substandard equipment. - We know this because they set up the replacement program for machines well out of warranty. Kudos to them for doing this, that was the right thing to do.
B) I don't believe it's conceivable that Apple did not discuss this workaround fix at some point. They will have made a conscious decision not to make the information easily available. I'll leave you to draw your own conclusions as to why they decided to do that but I decided they just wanted people to go out and buy another MacBook Pro ($$$$$$). I (personally) do not thing that was the right thing to do, its not a decision I would have made anyway.
Another thing to consider is that it would not have taken an Apple engineer very long at all to create an update to do all this in an automated way. Apple devices are often bought by people with limited technical knowledge. This fix will beyond the ability of many people. How MacBook Pro's have gone in the trash when they didn't have to?
I think it comes down to the difference between what you "have" to do and what you "should" do. When dealing with my clients/customers I always err towards what I "should" do. I don't believe Apple has done that with this issue.
Vc
[doublepost=1514106959][/doublepost]Hi all,
Thought I'd post the process I needed to follow to make this fix permanent on our 2011 MacBook Pro running El Capitan. The EFI var fix temporarily worked but would not survive a reboot. What I missed was the initial bit where AppleMacFinder moved the AMD Kext files and forced the rebuild of the driver cache. I've now rebooted our laptop 10+ times and the fix has stuck.
There is no new content in this post. All the really technical bits have been posted here by others, so props go to them. I've just pulled it together in to a process that worked for me in the hope it will help others. My notes prefixed with "Vc Note".
A) Boot off Arch Linux CD and set EFI variable to disable discreet AMD chip and get a clear display to work with:
===
=== 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 efivarfshas 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/
Vc Note: I had to do the above umount & mount every time I ran through this process.
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 (Vc NOTE: if this isn't the first time you've been through this process (it took me a few goes to get this working), you will probably have to run this command on the /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 file so you can delete it and recreate it with the printf command in the next step)
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
- + : Adds the attribute to the existing attribute of the files.
- – : Removes the attribute to the existing attribute of the files.
- = : Keep the existing attributes that the files have.
*) 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 (Vc Note: get ready to do the next bit straight away)
B) Boot to recovery prompt (cmd+R) and turn off System Integrity Protection. I found I couldn't move the Kext files without doing this.
- csrutil disabled
- reboot
C) Boot to OSX, open terminal and carry out the following (no need to do steps 1 & 2 and 8 & 9). It’s possible you’ll need to delete the contents of the AMD_Kexts folder first if this isn't the first time this has been done on the machine.
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
D) Reboot and repeat step A.
E) Boot to recovery prompt (cmd+R) and turn on System Integrity Protection.
- csrutil enable
- reboot
F) Boot in to OSX and disable automatic updates.
Vc NOTE: By disabling automatic updates you obviously won't receive Apple's security updates which will leave your machine vulnerable to exploits. It may be possible to accept updates and simply repeat the process above to get your MBP working again, however it is not something I've tested, and I was concerned that if the AMD problem got worse over time on my machine I may not be able to read the screen and apply this workaround. I consider the risk of switching off updates to be the price I've had to pay to get the machine working again and not have to buy a new laptop.
Apple didn't really make substandard equipment, it just so happened that the process they used on some of products failed. Even if they did, they didn't do it knowingly. Even if they did know, they kinda did something about it. In most cases, those machines that failed have been used well enough beyond whatever warranty they had, and we all know most people, like myself, use computers like there is no tomorrow. Even with the failures, those machines fared better than most other wintel machines of similar price points under similar use. Again, they didn't really have to do anything, even with the class suit, as most of the machines that started to fail were already way out of warranty.
That's all besides the point now. I'm not defending Apple, rather, I'm pointing out that this issue has been blown way out of proportion. Again, it sucks these machines failed. It sucks that the new machines have issues. But what sucks more is that people making it as if there's nothing else anyone could do. Whose to say we don't have an Apple engineer/programmer amongst us here that have been feeding us these workarounds?
Now, like I've mentioned, if my MBP failed earlier on while it's still under warranty, and Apple did nothing about it, then I'll scream bitching hell. Then again, I might not, since I don't really stress myself about things I don't have control over. It's under warranty. Apple will do something about it as they have. It was out of warranty, they still did something about it. It might sound like lip service to most people, but the thing is, when I had the logic board replaced for free, I already knew they issue will return, because they used the same logic board. I've seen people bitch about that after the fact. I already knew it coming, so I prepared myself for the worse
It's really simple. The day it came, I was already saving up. Unfortunately, what I have isn't enough, and with the issues of the 2017 models, I had back up plans of getting a 2015 model, or wait for the 2017 muck to clear up.
The best explanation ever. It work after I upgraded/ruined previous fixed on high sierra upgrade. Only yours work right now.
Last edited:
Yes. This XNU -> High Sierra 10.13
xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp:1121: PE_parse_boot_argn("darkwake", &gDarkWakeFlags, sizeof(gDarkWakeFlags));
Example (I did not test):
Darkwake decimal value:
Code:
sudo nvram boot-args="-v darkwake=1"or
Darkwake hexadecimal value:
Code:
sudo nvram boot-args="-v darkwake=0x01"
Code:
// gDarkWakeFlags
enum {
kDarkWakeFlagHIDTickleEarly = 0x01, // hid tickle before gfx suppression
kDarkWakeFlagHIDTickleLate = 0x02, // hid tickle after gfx suppression
kDarkWakeFlagHIDTickleNone = 0x03, // hid tickle is not posted
kDarkWakeFlagHIDTickleMask = 0x03,
kDarkWakeFlagAlarmIsDark = 0x0100,
kDarkWakeFlagGraphicsPowerState1 = 0x0200,
kDarkWakeFlagAudioNotSuppressed = 0x04000x -> hexadecimal -> 0x0200 hexadecimal -> 512 decimal
Example for high values for darkwake:
Darkwake decimal value:
Code:
sudo nvram boot-args="-v darkwake=512"or
Darkwake hexadecimal value:
Code:
sudo nvram boot-args="-v darkwake=0x0200"https://opensource.apple.com/source/xnu/xnu-4570.1.46/iokit/Kernel/IOPMrootDomain.cpp.auto.html
http://www.insanelymac.com/forum/to...id-wake-from-sleep-for-skylake-iris-graphics/
Darkwake Deciphered:
https://www.tonymacx86.com/threads/darkwake-deciphered.236850/
--------
If you want to get an idea about gpuswitch in the pmset command:
gpuswitch 0, 1, 2
https://opensource.apple.com/source...es/com.apple.SystemPowerProfileDefaults.plist
Last edited:
I tried overheating it again since it was the solution the first time the boot was stuck at half load (but on a clear screen with the Apple logo etc, not full of glitch) but it didn't work...
It really looks like the problem is worse now because the first things that appear on the screen when I boot are massive ugly glitches...
Sometimes I can barely see the black screen and white commands of the single user mode, and the keyboard is responding but only for a few secs...
Any ideas?
Well, looks like my logic board is going again. This is the 3rd time.
I am interested in the solution in this thread but very confused. I see some stuff on the first page, and then corrections on another.
1. Can someone please point me to the final solution post all in one?
2. Can anyone create some sort of download that does all of this in a couple of clicks? I am willing to pay for assistance here. Can someone do this on Team Viewer?
3. Do I have to use another machine that is Linux or something?
4. Is this reversible if I decide to replace the logic board at a later date?
5. What's the difference between this fix and the GRUB fix? What's a GRUB?
Sorry, but this is all a foreign language to me. I just want to get my machine running properly again.
Thank you,
MBPro17
I am interested in the solution in this thread but very confused. I see some stuff on the first page, and then corrections on another.
1. Can someone please point me to the final solution post all in one?
2. Can anyone create some sort of download that does all of this in a couple of clicks? I am willing to pay for assistance here. Can someone do this on Team Viewer?
3. Do I have to use another machine that is Linux or something?
4. Is this reversible if I decide to replace the logic board at a later date?
5. What's the difference between this fix and the GRUB fix? What's a GRUB?
Sorry, but this is all a foreign language to me. I just want to get my machine running properly again.
Thank you,
MBPro17
Last edited:
Hi MBPro17,
The final solution (known as the EFI fix) is at the end of the original post on page 1, the sub-heading is entitled '100% Working Solution'
You have to use another machine to create a bootable CD or USB key from an ISO image, it doesn't have to be a Linux machine.
It is 100% reversible.
I don't have good answers for your other questions so perhaps somebody else could chime in...
[doublepost=1514314462][/doublepost]As an aside, has anyone managed this fix on a BTO 2011 Mac Mini with faulty Radeon dGPU?
Last edited:
Hi guys ! I am new here.
My story : I purchased last week a MacBook Pro on Ebay for a cheap price. It was discribed as "White screen" MacBook pro 2010 with a core i5. But instead i received a MacBook Pro Early 2011 with core i7. The problem is that on the MBP 2010 a simple NVRAM reset fix this issue. On the Early 2011 version it's another story. So i have a better perf but a bigger problem...
So i did one thing:
Bake my macbook's mobo. The macbook start again, but when i switch to dGPU, after 2 minutes it's freeze and turns off.
At that time i have two solutions :
- Bake it again at a higher temp
- Fix Efi vars.
I have tryed to fix Efivars, but even if i (it seems that) did all the operations successfully, the Macbook seems to be able to switch on AMD gpu. For exemple when i start Photo booth, gfxcardstatus tell me that AMD card is now running.
Is that normal ?
Sorry for my bad english, i am French :S
Thanks you !
My story : I purchased last week a MacBook Pro on Ebay for a cheap price. It was discribed as "White screen" MacBook pro 2010 with a core i5. But instead i received a MacBook Pro Early 2011 with core i7. The problem is that on the MBP 2010 a simple NVRAM reset fix this issue. On the Early 2011 version it's another story. So i have a better perf but a bigger problem...
So i did one thing:
Bake my macbook's mobo. The macbook start again, but when i switch to dGPU, after 2 minutes it's freeze and turns off.
At that time i have two solutions :
- Bake it again at a higher temp
- Fix Efi vars.
I have tryed to fix Efivars, but even if i (it seems that) did all the operations successfully, the Macbook seems to be able to switch on AMD gpu. For exemple when i start Photo booth, gfxcardstatus tell me that AMD card is now running.
Is that normal ?
Sorry for my bad english, i am French :S
Thanks you !
The gpu-power-prefs NVRAM variable (EFI) is unique for all Macbooks, Mac Mini, Mac Pro, etc. At least MacIntel architecture.
Mac OS tested: El Capitan, Sierra and High Sierra.
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs
Apple decided to make life easier for Mac OS team developers.
This is set by AppleMuxControl.kext.
This can be verified by the grep command.
Code:
grep -iaRn gpu-power-prefs /System/Library/Extensions/
/System/Library/Extensions//AppleGraphicsControl.kext/Contents/PlugIns/AppleMuxControl.kext/Contents/MacOS/AppleMuxControl:115:
policygpu-policy
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-active
AGC:: Mux statemachine disabled, WS not ready
Last edited:
Hi guys, thanks for the solutions provided in this thread. Just a week ago my MBP 2011 AMD finally broke. But now I'm running again with the AMD switched off and the IntelHD working 
Just a few hiccups; I read till page 27 and then decided I could better just ask the question...
-The MBP can't seem to wakeup from sleep mode
-The brightness controles aren't working
anyone has a solution for this?
Just a few hiccups; I read till page 27 and then decided I could better just ask the question...
-The MBP can't seem to wakeup from sleep mode
-The brightness controles aren't working
anyone has a solution for this?
Hi nsgr,
Ive tried both the EFI fix on my Mac mini, as well as booting up in safe mode and entering the nvram command that is documented as part of the grub fix. But neither has any effect and the machine always uses the dGPU... so it either hangs on a grey screen at the end of the boot sequence, or (if I disable all the ATi-AMD Kexts) it works but with very slow unaccelerated graphics.
My Mac mini has two graphics outputs - an HDMI port, and Thunderbolt/mini-displayport. I know that on the MacBook Pro with dGPU the built in display is physically wired to the iGPU, and the Mini DisplayPort is wired to the dGPU (and therefore the fix only works for the built-in display). But how are things wired up on the 2011 Mac mini with Radeon dGPU? It might be helpful to know!
I was glad to find this post (thanks AppleMacFinder) but I had to do the re-flowing trick first to get any screen to come up at all. That worked
As it turned out my bootable file was no good because I dragged and dropped from downloads to blank disk. When I used the Disk Utility it worked fine.
I went through the whole sequence and hit reboot. All went well except that it appears to still be using the discrete GPU. I did not get the little "i" at the top of menu bar to confirm whether it was disabled or not. One thing I caught a glimpse of while it was scrolling in the Linux terminal mode was a single line that said "failed" and Archlinux was part of that line. Then it scrolled down and I could no longer see it. The computer is still working fine but I wanted to get the discrete GPU disabled before it craps out again. Actually 30 minutes later the screen went black and shut down, although it did restart again.
[doublepost=1514400076][/doublepost]
Be sure you use the disk utility. Don't drag and drop
Last edited:
If your gpu-power-prefs has the correct effect, then the Intel gpu driver will take over. Otherwise, the AMD gpu will be the primary gpu.
AMD gpu primary video (normal boot):
If the AMD kexts of your AMD gpu are in /System/Library/Extensions, then the Mac Mini will freeze on the gray screen.
If you moved AMD kexts from /System/Library/Extensions, then your AMD gpu being as primary, the AMD gpu will use the VGA Fallback Driver (slow unaccelerated graphics).
Verify your ActiveGPU:
1 - Boot in Safe Mode (press SHIFT key at boot).
2 - After load graphical interface -> open Terminal -> use ioreg command to list ActiveGPU - The -l option is required:
Code:
ioreg -l | grep -i ActiveGPU
| | | "ActiveGPU" = "IGPU"Just to be clear about your UUID gpu-power-prefs:
1 - Clear NVRAM / PRAM
2 - Clear SMC
3 - Boot with ArchLinux
4 - List UUID (numbers and letters) gpu-power-prefs:
Code:
ls -la /sys/firmware/efi/efivars/ | grep gpu-power-prefs
gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f95 - Is gpu-power-prefs exactly the same as below?
gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
You can also enforce gpu-power-prefs without UUID.
There will be two gpu-power-prefs for the Intel gpu. One with UUID (numbers and letters) and other without numbers and letters.
With the nvram -p command, only the NVRAM variables without UUID are shown.
Boot in Single User (Command + S)
1 - gpu-power-prefs with UUID:
Code:
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00Plus
2 - gpu-power-prefs without UUID
Code:
sudo nvram gpu-power-prefs=%01%00%00%00Other reinforcements:
3 - gpu-active set to Intel gpu:
Code:
sudo nvram gpu-active=%01%00%00%004 - gpu-policy set to Intel gpu:
Code:
sudo nvram gpu-policy=%01https://github.com/ah-/gmux-scripts/issues/1#issuecomment-68113930
Theoretically, Single User Mode does not need the sudo command because you are already logged in as the root user. But I use the sudo command anyway.
Some information about wired gpu:
Mac mini .... Primary Display ... Primary Connector(s) ... Secondary Display .. Secondary Connector
Mid-2011 ..... 2560x1600 x2* ........ Thunderbolt* ................. 1920x1200 .................. HDMI
(6630M*)
https://everymac.com/systems/apple/...aluminum-video-processor-display-support.html
https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i7-2.7-mid-2011-specs.html
Last edited:
I apologize if this has already been covered, but what is the easiest way to set the EFI back to the AMD Radeon GPU?
I successfully used the guide and other posts to modify my 2011 MBP 15's EFI to use Intel HD Graphics 3000. This works perfectly for macOS, but I have been unsuccessful in my attempts to get it to work with Windows 7 (which uses a BIOS-style boot rather than UEFI), so I am considering sending my laptop into a repair service to have the AMD GPU replaced. Just want to make sure it's set back to stock settings before that happens.
I successfully used the guide and other posts to modify my 2011 MBP 15's EFI to use Intel HD Graphics 3000. This works perfectly for macOS, but I have been unsuccessful in my attempts to get it to work with Windows 7 (which uses a BIOS-style boot rather than UEFI), so I am considering sending my laptop into a repair service to have the AMD GPU replaced. Just want to make sure it's set back to stock settings before that happens.