La forma en que se enmarca la pregunta en el título puede ser de interés general.
El problema o ejemplo concreto al que se debe aplicar esta pregunta es: Encontrar la solución óptima para hackear un MacBook Pro (chip de gráficos discretos AMD quemado) que de otro modo estaría muerto y volver a ponerlo en condiciones de uso.
Fondo:
Situación actual: dGPU frito, siempre se debe forzar el arranque en iGPU. Con la configuración de hardware predeterminada y la instalación del sistema predeterminada, la máquina simplemente no arrancará.
Efecto secundario no deseado por deshabilitar la dGPU en el software: AMDRadeonX3000.kext no debe cargarse de inmediato, si lo hace: el arranque se bloquea en Yosemite, se congela en Sierra y resulta en reinicios forzados rápidos debido al sobrecalentamiento en High Sierra antes de que la GUI esté activa. Los síntomas observables en Sierra, la última línea en el arranque detallado es:IOConsoleUsers IOScreenLockState 3.
No cargar el kext en absoluto: la gestión térmica para el chip AMD se sale de control. La temperatura nunca desciende por debajo de los 65 °C y aumenta fácilmente a pesar de que no se utiliza el chip.
Carga retrasada: todo está bien en el lado de la temperatura. La GPU no está inactiva a plena potencia, sino a un estado de potencia mucho más bajo. Según la versión del sistema operativo, los sensores informan temperaturas que oscilan entre 0 °C y 60 °C. Aunque esa lectura no parece realmente realista o confiable, toda la unidad también se mantiene más fría al tacto.
Pero "todo está bien" sólo la mayor parte del tiempo. De vez en cuando hay problemas de sueño muy raros en Sierra y, por desgracia, siempre en Yosemite.
Descubrir que el kext debe cargarse para ejecutar la máquina, pero es mejor no cargarlo (al menos de manera retrasada) para dormir la máquina: un intento del kextunloadkext aparentemente responsable da como resultado un pánico inmediato. Este párrafo es principalmente preocupante cuando se está en Yosemite, pero no tanto en Sierra.
Además de eso, puede que no sea la solución óptima. La gestión térmica necesita de 1 a 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 del controlador de gráficos en Sierra debe cargarse en/alrededor/después del arranque, automáticamente, pero más tarde.
Por supuesto, son interdependientes y todos se cargan según lo considere necesario el sistema en circunstancias normales.
Pero el sistema se colgará en 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 cargarlo manualmente o junto con un inicio de sesión de GUI a través de ganchos funciona.
Sin embargo, esto significa que colocar el kext en /System/Library/Extensionso /Library/Extensionsda como resultado un bloqueo en el arranque, ya que se consultan demasiado pronto.
Lo que tampoco funciona es usar daemons o agentes lanzados en todo el sistema, ya que estos también se consultan demasiado pronto. Los mismos demonios bajo jerarquías de usuarios aparentemente no tienen los privilegios necesarios para cargar un kext.
Entonces, ¿dónde tiene que ir este kext de /System/Library/Extensions? ¿Cómo se puede imponer un retraso para que este kext solo se cargue después de que se hayan cargado todas sus dependencias ascendentes o descendentes?
"¿Qué kext?" podrías preguntar. Esta pregunta es sobre todos los kexts de AMD, cada uno para ser probado individualmente.
Esto es un intento de mejorar aún más esta guía .
Preguntas
Pregunta principal: ¿Cómo se puede obligar a uno de esos kexts gráficos a una carga retrasada? (Aparte del método LoginHook).
Si esto resulta subóptimo para el objetivo declarado, también sería bueno, o incluso mejor, saber:
¿Existen otras formas en el software para mantener la dGPU deshabilitada bajo las reglas de administración térmica y de energía del sistema? (Mientras menos energía pase por este chip sin usar, mejor).
Ese caso también puede involucrar otras extensiones del kernel.
La solución más fácil es probablemente eliminar por completo la extensión del kernel infractora de /System/Library/Extensions, en su caso, AMDRadeonX3000.kext. Necesitas:
Deshabilite la protección de integridad del sistema. Hay muchas guías en Internet sobre cómo hacer esto, pero la versión corta es: reinicie en modo de recuperación, abra la terminal e ingrese csrutil disable.
Copie /System/Library/Extensions/AMDRadeonX3000.kext en un espacio seguro en otro lugar de su computadora, en caso de que algo salga mal y necesite revertirlo.
Elimine AMDRadeonX3000.kext de /System/Library/Extensions.
Limpia tu caché de kext. Abra la terminal y ejecute: sudo touch /System/Library/Extensions && sudo kextcache -u /. Luego reinicie.
El kext puede volver a aparecer después de actualizar macOS, en cuyo caso deberá repetir los pasos 3 y 4. Por esta razón, aunque puede volver a habilitar SIP una vez que se haya eliminado el kext, le recomiendo dejarlo desactivado.
La comunidad Hackintosh tiene métodos más persistentes para deshabilitar extensiones específicas del kernel. Si lo desea, puede considerar la instalación del cargador de arranque Clover, que está dirigido a usuarios de Hackintosh, pero también debería funcionar en hardware oficial. Sin embargo, para sus necesidades, creo que simplemente eliminar el kext es la mejor solución.
Editar : este método hará que la GPU dedicada continúe recibiendo energía, desperdiciando la batería. Para evitar que la GPU reciba energía, deberá instalar Clover y luego crear un SSDT personalizado que apague la GPU.
No existe una forma documentada para que un usuario (ni un administrador) retrase la carga de KEXT. Las extensiones del kernel del sistema están siendo cargadas por kextd, el "servidor de extensión del kernel" según su manpágina. kextdse inicia a launchdtravés de un LaunchDaemon sentado aquí:
/System/Library/LaunchDaemons/com.apple.kextd.plist
Además de este directorio launchdtambién consulta /Library/LaunchDaemons. No hay un orden definido de ejecución de las listas de LaunchDaemon y tampoco hay una opción de retraso. Eso lo hace por sus opciones, me temo.
/LibraryLaunchDaemon en formato canónico en 10.6 logra cargar el kext lo suficientemente tarde. ¿Es 10.6 lo suficientemente lento por sí solo o cambiaron el procesamiento/paralelización entre 10.6 y 10.12?<Nice>definición en kext .plist. P.ej. <key>Nice</key><integer>20</integer>Los valores van de -20 a 20. Los valores más bajos tienen una programación más favorable.
Alano
usuario3439894
LаngLаngС