The way the question in the title is framed might be of general interest.

The concrete problem or example that this question should be applied to is: Finding the optimal solution to hack an otherwise dead MacBook Pro (burned out AMD discrete graphics chip) back into usable condition.


Current situation: fried dGPU, boot has to be forced into iGPU always. With default hardware settings and default system installation the machine will simply not boot.

Unwanted side-effect for disabling the dGPU in software: AMDRadeonX3000.kext mustn't load immediately, if it does – boot hangs on Yosemite, freezes in Sierra and results in quickly forced reboots due to overheating in High Sierra before the GUI is up. Symptoms observable in Sierra, last line in verbose boot is: IOConsoleUsers IOScreenLockState 3.

Not loading the kext at all: thermal management for AMD chip gets out of hand. Temperature never sinks below 65°C and easily spikes higher despite the chip not being used.

Delayed loading: All is OK an the temperature side. GPU isn't idling at full power but idling at a much lower powerstate. Depending on OS version the sensors report temperatures ranging from 0°C–60°C. Although that reading seems not really realistic or trustworthy the whole unit also stays cooler to the touch.

But "all is well" only most of the time. Every now and then there are very rare sleep issues on Sierra, and alas: every time on Yosemite.

Finding that the kext needs to be loaded for running the machine but is better not loaded (in the delayed manner at least) for sleeping the machine: an attempt to kextunload the seemingly responsible kext results in an immediate panic. This one paragraph is mainly of concern when on Yosemite but not so much on Sierra.

On top of that it may not be the optimal solution. Thermal management needs 1-2 minutes in the current configuration after loading the kext to stabilise into acceptable levels. Therefore the desire to rotate the kexts and see what might give best results.

Steps taken so far:

One of the graphics driver kexts in Sierra needs to be loaded at/around/after boot, automatically, but later.

They are interdependent of course and all loaded as deemed necessary by the system under normal circumstances.

But the system will hang on boot if the one kext in question is loaded too early and the system runs exactly as desired if it is loaded later.

In this case I confirmed that loading it either manually or together with a GUI login via hooks works.

However, this means that placing the kext in /System/Library/Extensions or /Library/Extensions results in the hang on boot as they are consulted too early.

What also does not work is using system wide launchd agents or daemons since these are also consulted too early. Same daemons under user-hierarchies do apparently not have the necessary privileges to load a kext.

So where has this one kext from /System/Library/Extensions to go? How can a delay be enforced that this kext is only loaded after all its up or down dependencies have been loaded?

"Which kext?" you might ask. This question is about all the AMD kexts, each to be tested individually.

This is in an attempt to further improve this guide.


Main question: How can one of those graphics kexts be forced to a delayed load? (Other than the LoginHook method.)

If this proves suboptimal for the stated goal, it would be also nice, or even better to know:

Are there other ways in software to keep the disabled dGPU under the thermal and power management rules of the system? (The less power goes through this unsused chip the better.)

That case may involve other kernel extensions as well.

  • 1
    This sounds like an XY problem. What exactly is the issue that needs to get solved?
    – Allan
    Aug 28, 2017 at 15:56
  • Bite the bullet, replace the motherboard or buy a new Mac! Aug 29, 2017 at 13:02
  • I have newer macs. Replacing the motherboard is really unhelpful since Apple will not do it anymore at all. Even if they did, they only have had these defective and dying ones. It is a design flaw in HW. Mine had 4 new logic boards from Apple. Only replacing the AMD chip alone will fix it. Apple will not do that kind of component work and they prohibit AASPs from doing it. Then there are thousands still out who do not have the money willy-nilly. With the 'hack' we can continue on them and contribute to keeping this otherwise good machines from the waste pile. Aug 29, 2017 at 13:26

2 Answers 2


The easiest solution is probably to outright remove the offending kernel extension from /System/Library/Extensions, in your case AMDRadeonX3000.kext. You need to:

  1. Disable System Integrity Protection. There are many guides across the internet on how to do this, but the short version is: reboot into recovery mode, open the terminal, and enter csrutil disable.

  2. Copy /System/Library/Extensions/AMDRadeonX3000.kext to a safe space somewhere else on your computer, in case something goes wrong and you need to revert.

  3. Delete AMDRadeonX3000.kext from /System/Library/Extensions.

  4. Clear your kext cache. Open the terminal and run: sudo touch /System/Library/Extensions && sudo kextcache -u /. Then reboot.

The kext may reappear after updating macOS, in which case you'll need to repeat steps 3 & 4. For this reason, although you can re-enable SIP once the kext has been removed, I recommend just leaving it off.

The Hackintosh community has more persistent methods of disabling specific kernel extensions. If you'd like, you could look into installing the Clover bootloader, which is targeted at Hackintosh users but should work on official hardware as well. For your needs, however, I think simply deleting the kext is the best solution.

Edit: This method will cause the dedicated GPU to continue receiving power, wasting the battery. In order to stop the GPU from receiving power, you will need to install Clover and then create a custom SSDT that switches off the GPU.

  • 1
    I added an addendum to my answer based on clarification from the OP. Wrapping your head around Clover and custom SSDT's can be somewhat time consuming, but may be worthwhile depending on how long you intend to keep this machine. Aug 29, 2017 at 19:08

There’s no documented way for a user (nor an admin) to delay the loading of KEXTs. System kernel extensions are being loaded by kextd, the “kernel extension server” according to its man page. kextd is started by launchd via a LaunchDaemon sitting here:


In addition to this directory launchd also consults /Library/LaunchDaemons. There’s no defined order of execution of LaunchDaemon plists and there’s no delay option, either. That about does it for your options, I’m afraid.

  • Someone working on the same problem indicated that a /Library LaunchDaemon in canonical format on 10.6 succeeds in loading the kext late enough. Is 10.6 just slow enough on its own or did they change the processing/parallelisation between 10.6–10.12? Aug 28, 2017 at 9:36
  • It still is non-deterministic. Also, kexts are being put into a cache which will then be loaded at once on subsequent boots. This will further defeat any attempts to selectively delay kext loading.
    – Tom E
    Aug 28, 2017 at 9:57
  • @TomE - you can "sorta" schedule the loading with the <Nice> definition in the kext .plist. Eg. <key>Nice</key><integer>20</integer> The values go from -20 to 20. Lower values have more favorable scheduling.
    – Allan
    Aug 28, 2017 at 18:42
  • @Allan: The info.plist within the kext? & Isn't that part codesigned as well? –– @ Tom E.: The kext is already moved out of the canonical places for extensions, therefore the kextcache is not a problem. Aug 29, 2017 at 12:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .