Thank you for your report, dnewfield! Please tell me, do you have a clean display screen now? (screen that is not distorted by a failing discrete GPU) This information can be helpful to other people
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
- 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
When I remove AMD kexts (no other fixes), it boots but no acceleration, everything is slow, graphic-demanding apps (including preview) not working. If I use gfxcardstatus in integrated mode, igpu works the same as dgpu with all acceleration, a bit slower but ok, even photoshop and premiere. After some days it either freezes or doesnt wake or kernel task gets 100% of cpu and hangs on reboot. After using both gfxcardstatus (2.1.1) and gpu-switch in integrated mode I get good quality boot screens and normal boot but after some days boot hangs on 40%, only safeboot is working. After PRAM reset I get distorted screen/gray screen with fans etc. again, and no safeboot. So I conclude that both GCS 2.1.1 and gpu-switch successfully write something to PRAM(NVRAM) but it does not prevent osx from trying to access dgpu in some situations, for instance, in google maps or any graphic demanding apps. Eventually I have come to using both apps simultaneously. But it all comes to an end unpredictably.
AppleMacFinder, please clarify:
1. Did you remove AMD kexts after your EFI variable fix? If yes, why did you remove them? dnewfield, after variable fixing and removing kexts, is there any difference in acceleration etc? Does your MBP work after your fix like after switching via gfxcardstatus? How graphic demanding apps behave?
2. Also I have studied the gpu-switch code, I found it almost the same as AppleMacFinder's commands and I wonder is there any difference between your fix and what gpu-switch does? It appears that gpu-switch works on my machine (good boot screen and after boot the about screen reports intel gpu) but osx still tries to access dgpu from time to time with sad results...
What dnewfield reports is very similar to my experience with gpu-switch and GCS 2.1.1.
AppleMacFinder, please clarify:
1. Did you remove AMD kexts after your EFI variable fix? If yes, why did you remove them? dnewfield, after variable fixing and removing kexts, is there any difference in acceleration etc? Does your MBP work after your fix like after switching via gfxcardstatus? How graphic demanding apps behave?
2. Also I have studied the gpu-switch code, I found it almost the same as AppleMacFinder's commands and I wonder is there any difference between your fix and what gpu-switch does? It appears that gpu-switch works on my machine (good boot screen and after boot the about screen reports intel gpu) but osx still tries to access dgpu from time to time with sad results...
What dnewfield reports is very similar to my experience with gpu-switch and GCS 2.1.1.
I used rufus rather than terminal, 100% ok! Thanks.
Now following this step:
"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!"
When I do this, the result is the upper left of the screen says:
running early hook
blah
blah
blah
blah (udev)
Triggering events....
Then the screen fades to white from upper left to lower right, then either stays white or turns black, nothing else happens. What am I doing wrong?
[EDIT] After trying this 5-6 times, it shut off and the power button is no longer responsive.
Now following this step:
"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!"
When I do this, the result is the upper left of the screen says:
running early hook
blah
blah
blah
blah (udev)
Triggering events....
Then the screen fades to white from upper left to lower right, then either stays white or turns black, nothing else happens. What am I doing wrong?
[EDIT] After trying this 5-6 times, it shut off and the power button is no longer responsive.
Last edited:
Just wanted to report that my MBP is up and running! I went through the procedure so many times I can't be sure at what point it started working haha, but it went from being impossible to boot to working basically like it did before. Many many thanks for this AppleMacFinder.
Finally you have defeated this evil machine!
Humans are stronger than computers Congratulations, roberthallin! Just one question: did you remove the AMD drivers from your MBP (as described in that 1st message) or they are still there? In theory this should not affect the end result, I am just curious
No, I removed AMD kexts before the EFI variable fix
Their removal was necessary to successfully boot the MBP (although with a sh!tty distorted graphics) . At this point of research I hoped that it is possible to just use gfxCardStatus to switch to "Integrated only", but it turned out that its impossible because of that "External display" (which in fact is internal) using the discrete GPU. Even after I have installed XCode and a bunch of other stuff (although the text was a bit difficult to see) to rebuild gfxCardStatus without a check for external displays, it still has not been able to work successfully. Only then, after researching it further, I have discovered this EFI variable fix - so when I did it the AMD drivers have already been removed (although in theory their removal should not impact the end results, the people could still try it to see if it helps)
This question is addressed to dnewfield but I will still reply regarding my experience... After doing that EFI variable fix with my MBP, all image goes from the working Integrated graphics, so a screen is completely clean (no distortions!) Even while running the graphic demanding apps, like the video games, Integrated graphics always remains in use - it is even impossible to switch to discrete GPU in gfxCardStatus when you are trying to do it on purpose! So far I have been surprised that one video game that I like - was playable at medium settings (although with a few lags sometimes). Mac's desktop also works almost perfectly, although there are a few lags as well - but these small lags are OK
If I understand it correctly, gpu-switch is aimed to switch the graphics after you have booted your MBP, even during the runtime - but in my case the gpu-switch was not working, probably because it tried to change the EFI variable at some later booting stage (either while login or during the runtime, depending on how you use it) , and this "External display" block - was already in action. So I reviewed gpu-switch code and used some notes from it to modify this EFI variable permanently with a correct value. And now my Mac is permanently on integrated graphics, it never tried to switch to discrete graphics even when I launched some video games
[doublepost=1490351196][/doublepost]
Hi TitusVorenus ! Please tell, in what mode did you write .iso file in Rufus? There are two modes in Rufus - ISO mode and dd mode. If you did it in ISO mode, I recommend creating a LiveUSB again in Rufus but this time in dd mode - so that it would be the same as if you would have created it from a terminal. Hopefully you added a SPACE character before the nomodeset option, to avoid it from merging with another boot option. Also, while the booting process should be quick, please wait at least 5 minutes - before deciding that it is stuck and forcing a reboot by holding the power button. If any other problems, reset your PRAM / NVRAM / SMC and then try booting again:
1) PRAM / NVRAM clean: https://support.apple.com/en-us/HT204063
2) SMC clean: https://support.apple.com/en-us/HT201295
Probably your battery is at low charge levels. Please charge your MBP before trying again,
and maybe its better to have it connected to a power adapter while you are trying all these instructions
Last edited:
AppleMacFinder, thank you for detailed answers! Just as a report: when I removed kexts (I simply removed all AMD*.kext in single user mode) the screen was distorted during boot but clear after login. It was soooo slow and many apps not working... And yes, not switchable by GCS. So I had to put kexts back -> no boot -> forced overheat shutdown -> boot on igpu -> switch via GCS 2.2.1 / gpu-switch -> reboot on igpu. That was my scenario, repeatedly used sometimes once in a week or so, sometimes almost every day after using photoshop or premiere). Now there is a great hope that it will be fixed more reliably! I will try to follow exactly your instructions on kexts removal and then EFI fixing.
Yes, the display was clean after the efi mod in arch linux, but boot would stall at 50% until I removed all the AMD kexts. Everything seems to be working perfectly now (with slow graphics of course).
For the record, it's a MacBook Pro 15" early 2011, El Capitan.
Ok, I made the change to dd mode in Rufus, added the space before nomodeset, and got to step 3! Somehow the full battery was used up, which was fast discharge, but now the machine is working again after plugging it back in. I also did the PRAM and SMC clean.
Now, I typed the following commands:
*) cd /
*) umount /sys/firmware/efi/efivars/ got the
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/
and I'm in:
root@archiso /sys/firmware/efi/efivars #
Is the next step to:
rm gpu-power-pre and then press TAB key for autocompletion
or
chattr -i "/sys/firmware/efi/efivars/"
?
Then follow with this exact text entry as stated in the guide?
*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
*) chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"
*) cd /
*) umount /sys/firmware/efi/efivars/
*) reboot
Sorry for the step by step questions, I am a noob with command lines. I tried following the instructions further, but do not think I understood correctly, took a break after attempting the guide further, and the power cord dropped off and the machine ended up restarting. The machine no longer goes to the apple folder on normal restart, it now goes to a folder and "?".
I booted to archlinux again and now am at stage 3.
I just signed-up to report that this method has worked on an once abandoned MBP with failing discrete graphics. I had been fiddling for a week before giving up with the similar solutions using grub, refit, clover... I was only able to disable the amd card but couldn't get the internal display to work. Anyways, this works! Kudos! I find it interesting that it didn't completely disable the AMD card since it still shows up on the system profiler. Before this I was using a combination of gfxCardStatus 1.8 and gpuswitch which seemed to enable integrated graphics but with many glitches related to still trying to use the discrete card. It was ok for browsing and basic tasks but couldn't use Photos app which was a waste of the otherwise working 15" screen. Thanks!!
You need to follow the instructions at exactly the same order as they are described in my first message of this thread
If you have a trouble following this instruction, you could show this instruction to your friend who is more experienced with computers and ask for his help. However, I thought that these instructions are rather clear and easy-to-understand...
In case the HFS+ filesystem of your MBP got corrupted, you could still try booting in a single user mode and repairing the filesystem; if it does not help, it is possible to repair it under Linux (like I have described at the 1st message) - a bit difficult, but definitely doable
After you'll have more questions, feel free to ask them
Last edited:
I tried again, I was just not sure of the linux feedback I was getting I think. It worked this time, the screen is normal!
I cannot boot to single user mode, I get the same grey screen with a "?" on a folder blinking. I am replacing the hard drive in this machine. I assume that's not going to help as this is now a firmware problem. Could you please help me identify which part of the first message contains the next steps I will need to repair this under Linux? I would give it a go on my own, but after reading the first post again 2 times just now, I am not confident I can pick out the proper section to follow.
BTW, I didn't think I could get this far. Thank you!!!!
Hi AppleMacFinder,
I mounted a USB stick under Linux (FAT32) and mounted the /sys/firmware/efi/efivars following your procedure. From this point, I cannot copy the gpu-power file to the USB stick. It keeps telling me:
cp: error reading 'gpu-power-pref-xxxxxx': Invalid argument (xxxxxx represents all the numbers....)
Actually, I cannot do anything with the file. "mv" or anything else gives the same error. Remember that I could not do the hexdump either with the file for the same reason. There are no trailing spaces in the file name.
What is going wrong here? There seems to be something with the filename? It is not the USB stick, since copying this gpu file to another file to the same location does not work either...
Thanks for your help.
I'm very happy about your success
You have two options now:
1) If your screen is normal now, that means you can boot to OS X Installation DVD/USB now - and it has Disk Utility, using which it could be possible to repair your filesystem
2) Or, alternatively, you could do these steps:
But for that you need a spare computer with Linux installed or Linux LiveCD launched (preferably Ubuntu LiveCD, for beginners in the Linux world...) , and as you can see its a bit lengthy process, so hopefully you could avoid it with "1)"
[doublepost=1490550651][/doublepost]
I am not sure why you can't copy this file, weirdly it acts like it is a write-only... To be honest, I never tried copying or hexdumping this file before, because in my case this fix worked from the first time. Sadly its impossible to teleport to you and debug these problems together, but I wish you all the best and believe that after a few more attempts you will fix your MBP
I have successfully done the fix, it’s working like a charm!
I am so happy after three months of trouble!
AppleMacFinder, thank you, thank you, and thank you!!!
Some comments, maybe helpful for others:
1. Unmount and remount /sys/firmware/efi/efivars/ in rw mode was necessary.
2. chattr -i "/sys/firmware/efi/efivars/" did not work (error: Inappropriate ioctl for device while reading flags on /sys/firmware/efi/efivars). So I suppose that it is a mistake in the instruction. Used chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" instead (first -i to remove the file, then after prinf with +i to protect it).
In all other respects everything went fine!
I am so happy after three months of trouble!
AppleMacFinder, thank you, thank you, and thank you!!!
Some comments, maybe helpful for others:
1. Unmount and remount /sys/firmware/efi/efivars/ in rw mode was necessary.
2. chattr -i "/sys/firmware/efi/efivars/" did not work (error: Inappropriate ioctl for device while reading flags on /sys/firmware/efi/efivars). So I suppose that it is a mistake in the instruction. Used chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" instead (first -i to remove the file, then after prinf with +i to protect it).
In all other respects everything went fine!
Thanks AppleMacFinder!
This solution did indeed work for me, and I as a command line noob I was able to get everything working properly and have got my 17in MBP up and running again! As a noob, I encountered some problems, so I'm going to post the steps I followed here which will hopefully allow other noobs to get 'er done faster.
At this point, I referenced this post and followed these instructions, because when i didn't I got no results.:
At this point I continued following AppleMacFinder's instructions (part 3):
This switched to integrated graphics on boot. However something happened to my hard drive (commentary earlier in this thread). I was not able to reinstall OSX properly with the drive in the computer, so I had to pull it and reinstall. Then, I updated OSX after reinstalling the hard drive and the integrated graphics stopped working.
The OSX updates with the hard drive installed reversed the changes I made in Linux.
So I went through the process again to switch to integrated graphics full time. Then I pulled the hard drive and reinstalled OSX with all updates. I reinstalled the hard drive (now an SSD) and it's working faster and cooler than it ever has before!
This solution did indeed work for me, and I as a command line noob I was able to get everything working properly and have got my 17in MBP up and running again! As a noob, I encountered some problems, so I'm going to post the steps I followed here which will hopefully allow other noobs to get 'er done faster.
At this point, I referenced this post and followed these instructions, because when i didn't I got no results.:
At this point I continued following AppleMacFinder's instructions (part 3):
This switched to integrated graphics on boot. However something happened to my hard drive (commentary earlier in this thread). I was not able to reinstall OSX properly with the drive in the computer, so I had to pull it and reinstall. Then, I updated OSX after reinstalling the hard drive and the integrated graphics stopped working.
The OSX updates with the hard drive installed reversed the changes I made in Linux.
So I went through the process again to switch to integrated graphics full time. Then I pulled the hard drive and reinstalled OSX with all updates. I reinstalled the hard drive (now an SSD) and it's working faster and cooler than it ever has before!
Is it guaranteed the dgpu will go bad like many original xbox 360 and nvidia chips from 2008ish. My wife has one and it work perfectly fine but I may replace it before the inevitable.
Well, sure it's guaranteed to fail eventually, like every other bit of hardware, but if it's still working fine, why replace it?
We've got thinkpads running 10+ years 24/7 in mostly run all the time in case we need to remote into them.
As you can see by my case, even if discrete GPU worked for 6 years - it does not guarantee that it is fault free. Aside from the batteries/keyboards, which ARE replaceable by user (with some efforts), this GPU is probably the next thing in the list that is going to fail. If having a working discrete GPU is a requirement for your activities, and you got a spare $35, you might buy this replacement chip in advance - ( 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 ) - in advance, its' supplies will not last for forever... Otherwise, just bookmark this instruction, keep enjoying your discrete GPU while it lasts, then after it will fail - switch to integrated graphics with this EFI variable fix
Last edited:
Hi everyone,
Been using these forums for a while so thanks to all for being really very helpful.
It seems my Mac is fairly bricked, GPU failure on a late Mac 2011.
Apple offered to extend the repair program but once it got to the raptor shop they decided they couldn't help.
I've read that the GPU can be replaced, but the people I've called locally don't seem to think this will fix the problem.
I should note that I don't get any garbled screen or text, but it hangs or turns grey.
What I'm trying to do to get the Mac to bypass the GPU and only use integrated, right?
I tethered booted to another machine and used a program gfx-something to only use the integers GPU but I suspected that wouldn't work.
I found your thread and it seems really useful but in single user mode it won't grant me write privileges, any ideas?
Im not very good at this type of type, and unix is something i know nothing about.
Been using these forums for a while so thanks to all for being really very helpful.
It seems my Mac is fairly bricked, GPU failure on a late Mac 2011.
Apple offered to extend the repair program but once it got to the raptor shop they decided they couldn't help.
I've read that the GPU can be replaced, but the people I've called locally don't seem to think this will fix the problem.
I should note that I don't get any garbled screen or text, but it hangs or turns grey.
What I'm trying to do to get the Mac to bypass the GPU and only use integrated, right?
I tethered booted to another machine and used a program gfx-something to only use the integers GPU but I suspected that wouldn't work.
I found your thread and it seems really useful but in single user mode it won't grant me write privileges, any ideas?
Im not very good at this type of type, and unix is something i know nothing about.
Attachments
First up, big big thanks to AppleMacFinder for creating this solution, and to those others who have helped progess it.
I have an early 2011 MBP 17" with a fried graphics card as of mid-January, so it's been good to get it back. In my case, I could boot into Single User Mode. I could also boot into OSX proper when in SMC Debug mode, but the constantly roaring fans did my head in, so once I had all my files backed up, away it went. This mode bypasses a lot of things, including the discrete graphics card. However, programs could still call the dGPU, causing a freeze, requiring a hard shutdown. I soon lost the ability to boot into my Snow Leopard partition, but could still boot into my El Capitan (10.11.6) partition.
I was delighted to find a firmware fix, so went about applying it. Enduring the fans, I prepared the bootable Arch installer.
To clear the SMC Debug mode I did an SMC reset, followed by a PRAM reset. Being curious, I immediately booted into the Arch installer to see what was in my NVRAM. Turns out, all 3 GPU- ... variables were gone, as was the gfx-saved-config-restore-[GUID]
QUESTION: Based on that, would it be safe to experiment with different values for these GPU variables (using printf), on the basis that I can clear the NVRAM of those values if the display fails to come up? Or is there a risk of bricking the firmware?
My first attempt failed to finish booting. I (belatedly) recalled that Snow Leopard wasn't booting, so I booted into Single User Mode (which showed it was the Snow Leopard partition was now the default boot) and applied:
/sbin/fsck -fy
It gave the result that the Volume appears OK, as well as "The volume was modified". Conventional wisdom says keep running fsck until it doesn't give the "Volume was modified" message. The next fsck gave the all clear, so it was:
shutdown -h now
to get out of Single User Mode (note: typing "exit" will cause the normal boot process to occur, which I didn't want.)
I booted into the Arch installer as per instructions.
I re-mounted the efivarfs as read/write
As there was no gpu-power-prefs-[GUID], I created it with printf, then made it immutable
Unmounted, then rebooted.
This first boot was rougher than the Millenium Falcon jumping into hyperspace - to get to the login screen took just over 2 minutes (versus around 30 seconds when things were good) - but it finally made it!
Woo-hoo! I have an almost-fully-functional MBP!
ALMOST?
Well, one thing I didn't do is move the kexts out and re-build the kext cache. Again, I was curious. Here are the consequences:
1) Energy Savings Pane in System Preferences still has "Automatic Graphics Switching" available and selected.
2) Playing or even previewing any movie file causes freeze, requiring a hard shutdown. Fortunately, the EFI fix seems persistent, as I was able to boot up again.
3) Safari will work OK, until some website video will call on the dGPU, causing a freeze etc.
4) Firefox has been fine, as I've switched its "Hardware Acceleration" option off.
5) Although the fix survives a hard shutdown, it curiously did not survive a Restart from the login screen. I'm not sure if something went wrong that one time, or if it's something peculiar to my setup, or if the Restart process itself reliably causes this.
I applied the same steps again (including first going into Single User Mode to fsck the Snow Leopard. Again, it found something to modify). It worked first time through. Still haven't kicked the kexts out. Later.
My conclusion is that, with the kexts still in place, setting the gpu-power-prefs- as per this guide (and as per SwitchGPU?) doesn't strictly disable* the dGPU. Rather, only the iGPU is enabled and the dGPU is not enabled during the boot process, but the OS is still aware of the dGPU (Graphics Switching in System Preferences), and programs can try to use it later (and crash the MBP).
*Strictly disable:
1) dGPU is powered off
2) OS is not aware of it
3) dGPU cannot be invoked/used/poked.
What are your thoughts on 1) ? Does this process also power off the dGPU? (Is such a state even possible?)
My experience is that in Single User Mode, and in Arch installer, my MBP heated up (quickly, and substantially) at the left rear (magsafe - Esc key area). With the gpu-power-prefs altered, there's a slight warmth, but only where it is resting on a stand. So I would say my dGPU is not powered up.
As for 2) and 3), currently, moving out the kexts (plus the EFI fix) as per this guide is the way to go.
My wishlist would be to just edit the EFI variables to achieve all 3, but it seems that the relevant information (of how to do it - indeed, of "is it even possible?") is unavailable or well hidden.
It's been fun
PS This was posted as a Reply to a few posts, but due to a wardrobe malfunction, I didn't actually Quote and respond to those posts. Doh! Apologies to all
I have an early 2011 MBP 17" with a fried graphics card as of mid-January, so it's been good to get it back. In my case, I could boot into Single User Mode. I could also boot into OSX proper when in SMC Debug mode, but the constantly roaring fans did my head in, so once I had all my files backed up, away it went. This mode bypasses a lot of things, including the discrete graphics card. However, programs could still call the dGPU, causing a freeze, requiring a hard shutdown. I soon lost the ability to boot into my Snow Leopard partition, but could still boot into my El Capitan (10.11.6) partition.
I was delighted to find a firmware fix, so went about applying it. Enduring the fans, I prepared the bootable Arch installer.
To clear the SMC Debug mode I did an SMC reset, followed by a PRAM reset. Being curious, I immediately booted into the Arch installer to see what was in my NVRAM. Turns out, all 3 GPU- ... variables were gone, as was the gfx-saved-config-restore-[GUID]
QUESTION: Based on that, would it be safe to experiment with different values for these GPU variables (using printf), on the basis that I can clear the NVRAM of those values if the display fails to come up? Or is there a risk of bricking the firmware?
My first attempt failed to finish booting. I (belatedly) recalled that Snow Leopard wasn't booting, so I booted into Single User Mode (which showed it was the Snow Leopard partition was now the default boot) and applied:
/sbin/fsck -fy
It gave the result that the Volume appears OK, as well as "The volume was modified". Conventional wisdom says keep running fsck until it doesn't give the "Volume was modified" message. The next fsck gave the all clear, so it was:
shutdown -h now
to get out of Single User Mode (note: typing "exit" will cause the normal boot process to occur, which I didn't want.)
I booted into the Arch installer as per instructions.
I re-mounted the efivarfs as read/write
As there was no gpu-power-prefs-[GUID], I created it with printf, then made it immutable
Unmounted, then rebooted.
This first boot was rougher than the Millenium Falcon jumping into hyperspace - to get to the login screen took just over 2 minutes (versus around 30 seconds when things were good) - but it finally made it!
Woo-hoo! I have an almost-fully-functional MBP!
ALMOST?
Well, one thing I didn't do is move the kexts out and re-build the kext cache. Again, I was curious. Here are the consequences:
1) Energy Savings Pane in System Preferences still has "Automatic Graphics Switching" available and selected.
2) Playing or even previewing any movie file causes freeze, requiring a hard shutdown. Fortunately, the EFI fix seems persistent, as I was able to boot up again.
3) Safari will work OK, until some website video will call on the dGPU, causing a freeze etc.
4) Firefox has been fine, as I've switched its "Hardware Acceleration" option off.
5) Although the fix survives a hard shutdown, it curiously did not survive a Restart from the login screen. I'm not sure if something went wrong that one time, or if it's something peculiar to my setup, or if the Restart process itself reliably causes this.
I applied the same steps again (including first going into Single User Mode to fsck the Snow Leopard. Again, it found something to modify). It worked first time through. Still haven't kicked the kexts out. Later.
My conclusion is that, with the kexts still in place, setting the gpu-power-prefs- as per this guide (and as per SwitchGPU?) doesn't strictly disable* the dGPU. Rather, only the iGPU is enabled and the dGPU is not enabled during the boot process, but the OS is still aware of the dGPU (Graphics Switching in System Preferences), and programs can try to use it later (and crash the MBP).
*Strictly disable:
1) dGPU is powered off
2) OS is not aware of it
3) dGPU cannot be invoked/used/poked.
What are your thoughts on 1) ? Does this process also power off the dGPU? (Is such a state even possible?)
My experience is that in Single User Mode, and in Arch installer, my MBP heated up (quickly, and substantially) at the left rear (magsafe - Esc key area). With the gpu-power-prefs altered, there's a slight warmth, but only where it is resting on a stand. So I would say my dGPU is not powered up.
As for 2) and 3), currently, moving out the kexts (plus the EFI fix) as per this guide is the way to go.
My wishlist would be to just edit the EFI variables to achieve all 3, but it seems that the relevant information (of how to do it - indeed, of "is it even possible?") is unavailable or well hidden.
It's been fun
PS This was posted as a Reply to a few posts, but due to a wardrobe malfunction, I didn't actually Quote and respond to those posts. Doh! Apologies to all
Last edited:
Hi Bwil10,
This is indeed a really useful thread for those of us suffering dGPU failure in our MBPs.
From what I've read, at some point in the boot sequence, some process calls the dGPU, which fails to respond, at which point the boot process hangs. Grey screen and lamentations follow.
So we want the dGPU to be totally ignored, always, and only have the iGPU being used.
The method posted here is the only method I've found that achieves this aim.
I found that gfxCardStatus wasn't useful when the dGPU has already failed. When I was running my MBP in SMC Debug mode, I installed gfxCardStatus. It showed I was on Dynamic Switching. When I selected "Integrated Only", my MBP would freeze, and a hard shutdown was needed. I concluded that the dGPU was being "called" in some way (even though I was switching away from it), crashing the MBP in the same way playing a video, or launching iMovie, would crash the MBP.
I was curious about the GPU being replaced - can you elaborate on that?
And now, a warm welcome to the Command Line Universe!
If you are totally new to using Command Line Interfaces (CLI), my best words would be to double check what you type, before you press Enter. (I can get a bit OCD about long entries, and sometimes check them 3 or 4 times, and even then still make a typo).
Spaces are important. For many commands, the only consequence is that nothing happens other than a message. For some commands, a space in the wrong place, or the wrong number of spaces, can have middling to dire consequences (like wiping your entire hard drive).
Googling a command can be quite helpful - you can find out how it has been used, what it can't do, and what disasters people have had with it.
When you are in the CLI itself, you can always bring up a manual about a command by typing:
man [command]
e.g. to get info about the shutdown command:
man shutdown
Typically, pressing q will quit you out of the manual and put you back to the command prompt. For more info about manuals, type:
man man
It was good you posted the pic. There is one space missing in the mount command (after uw):
/sbin/mount uw/
Should be:
/sbin/mount uw /
With that you should have read/write privileges, and from there move the kexts etc.
I also see that fsck has modified the volume. It's a good idea to run fsck again until it doesn't give you "the volume was modified" message. It doesn't always pick up every problem the first time it runs.
Finally, I love the idea of a raptor shop. I want one. A shop, that is, full of raptors. Cheers
That will not fix a problem ONLY if you "repair" it at Apple, because Apple will just replace your faulty motherboard with another faulty motherboard but which is not showing a problem, yet... So Apple's fix is a temporary fix
^^^ This hardware fix is a real fix, not Apple's "fix", but it requires spending the money - and, if you don't need the discrete graphics for your activities, better to go with this software solution of disabling the failed discrete graphics permanently - which is described in this guide
Yes, this solution is a permanent switch to integrated GPU, to make your MBP bootable and work OK
Yes, gfxCardStatus can not be used for the permanent switch to integrated only. That is why this solution has been created
Most likely that means your HFS+ filesystem is slightly corrupted and that is why no write permissions. Looks like you have to repair your HFS+ filesystem before going forward.
Use fsck -fy command to repair your filesystem, and at your command from screenshot - mount -uw / - you forgot to write a SPACE character before / (you wrote mount -uw/ , should write mount -uw / )
[doublepost=1491132264][/doublepost]
I believe that if you use the wrong value of that GPU gpu-power-prefs-... variable, it will either not work or will act as one of the defined behaviors (dynamic switching / integrated only / discrete only) which are described at this file - https://github.com/0xbb/gpu-switch/blob/master/gpu-switch Even if you somehow mess up your other EFI variables (on purpose?
) and make your MBP unbootable, it should be possible to reset their values with PRAM/NVRAM/SMC resetsOS is still aware of the dGPU, yes, but it will be impossible to even enable it manually with gfxCardStatus. Even when I launch some graphics-demanding applications like the video games, MBP is NOT switching from integrated to discrete. So this software fix of permanently switching to integrated GPU - is quite reliable
From your list, I am confident that 3) works OK , but not sure if 1) or 2) are possible. 1) dGPU is powered off - even while you are at this Integrated only mode, the discrete GPU still will consume some power (although the small power) because of the hardware design 2) OS is not aware of it - OS will always be aware of it because the discrete GPU is connected to CPU through the PCI lines, so OS will always notice this discrete GPU - but it will never be able to use it because of this software EFI variable fix
Please see above
Even if you remove the kexts, that GPU will still be visible to CPU through PCI lines, and will be slightly powered because of the hardware design
Probably he has been referring to:
I am confident that this hardware fix will work, because this is a real fix, not an Apple "fix" (replace a faulty motherboard with another faulty motherboard which just is not showing a problem yet) But probably its not a good idea to invest the money to old computers unless you desperately need that discrete graphics for your activities
Last edited: