La forma en que se encuadra la pregunta en el título puede ser de interés general.
El problema concreto o ejemplo al que se debe aplicar esta pregunta es: Encontrar la solución óptima para piratear una MacBook Pro (chip de gráficos discretos AMD quemados) de nuevo en un estado utilizable.
Background:
Situación actual: dGPU frito, el arranque debe forzarse siempre en iGPU. Con la configuración de hardware predeterminada y la instalación predeterminada del sistema, la máquina simplemente no arrancará.
Efectos secundarios no deseados para deshabilitar el dGPU en el software: AMDRadeonX3000.kext no debe cargarse de inmediato, si lo hace: el inicio se bloquea en Yosemite, se congela en Sierra y produce reinicios forzados rápidamente debido al sobrecalentamiento en High Sierra antes de la GUI depende. Síntomas observables en Sierra, la última línea en el arranque detallado es: IOConsoleUsers IOScreenLockState 3.
Sin cargar el kext en absoluto: la gestión térmica del chip AMD está fuera de control. La temperatura nunca desciende por debajo de 65 ° C y aumenta fácilmente a pesar de que el chip no se está utilizando.
Carga demorada: todo está bien y el lado de la temperatura. La GPU no está inactiva a plena potencia, sino inactiva en una potencia mucho más baja. Dependiendo de la versión del sistema operativo, los sensores reportan temperaturas que oscilan entre 0 ° C y 60 ° C. Aunque esa lectura no parece realmente realista ni confiable, toda la unidad también se mantiene fresca al tacto.
Pero "todo está bien" solo la mayor parte del tiempo. De vez en cuando hay problemas de sueño muy raros en Sierra y, por desgracia, en Yosemite.
Encontrar que se necesita cargar el kext para ejecutar la máquina, pero es mejor no cargarlo (al menos de manera retardada) para dormir la máquina: un intento de kextunload del kext aparentemente responsable da como resultado un pánico inmediato. Este párrafo es principalmente de preocupación cuando se está en Yosemite pero no tanto en Sierra.
Además de eso, puede que no sea la solución óptima. La administración térmica necesita 1-2 minutos en la configuración actual después de cargar el kext para estabilizarse en niveles aceptables. Por lo tanto, el deseo de rotar los kexts y ver qué podría dar mejores resultados.
Pasos tomados hasta ahora:
Uno de los kexts de controlador de gráficos en Sierra debe cargarse en / alrededor / después del arranque, automáticamente, pero luego.
Por supuesto, son interdependientes y todos se cargan según lo considere necesario el sistema en circunstancias normales.
Pero el sistema se bloqueará durante el arranque si el kext en cuestión se carga demasiado pronto y el sistema se ejecuta exactamente como se desea si se carga más tarde.
En este caso, confirmé que la carga, ya sea de forma manual o junto con un inicio de sesión de GUI a través de enlaces, funciona.
Sin embargo, esto significa que colocar kext en /System/Library/Extensions o /Library/Extensions da como resultado el bloqueo en el arranque, ya que se consultan demasiado pronto.
Lo que tampoco funciona es el uso de demonios o agentes de lanzamiento en todo el sistema, ya que estos también se consultan demasiado pronto. Los mismos demonios en las jerarquías de usuarios aparentemente no tienen los privilegios necesarios para cargar un kext.
Entonces, ¿a dónde debe ir este kext de / System / Library / Extensions? ¿Cómo se puede imponer una demora para que este kext solo se cargue después de que se hayan cargado todas sus dependencias hacia arriba o hacia abajo?
"¿Qué kext?" usted podría preguntar Esta pregunta es sobre todos los kexts de AMD, cada uno para ser probado individualmente.
Esto intenta mejorar aún más esta guía .
Preguntas
Pregunta principal: ¿Cómo puede uno de esos kexts gráficos ser forzado a una carga retrasada? (Aparte del método LoginHook).
Si esto resulta subóptimo para el objetivo establecido, también sería bueno, o incluso mejor saberlo:
¿Hay otras formas en el software para mantener el dGPU deshabilitado bajo las reglas de administración de energía y energía del sistema? (Cuanto menos energía pase a través de este chip no utilizado, mejor).
Ese caso también puede involucrar otras extensiones del kernel.