La façon dont la question du titre est formulée peut être d'intérêt général.
Le problème concret ou l'exemple auquel cette question devrait s'appliquer est le suivant : Trouver la solution optimale pour remettre en état de marche un MacBook Pro qui serait mort (puce graphique discrète AMD grillée).
Contexte :
Situation actuelle : dGPU grillé, le démarrage doit toujours être forcé dans iGPU. Avec les paramètres matériels par défaut et l'installation système par défaut, la machine ne démarre tout simplement pas.
Effet secondaire indésirable de la désactivation du dGPU dans le logiciel : AMDRadeonX3000.kext ne doit pas se charger immédiatement, si c'est le cas - le démarrage se bloque sur Yosemite, se fige sur Sierra et entraîne des redémarrages forcés rapides dus à la surchauffe sur High Sierra avant que l'interface graphique ne soit en place. Symptômes observables dans Sierra, la dernière ligne dans verbose boot est : IOConsoleUsers IOScreenLockState 3.
Ne pas charger le kext du tout : la gestion thermique des puces AMD devient incontrôlable. La température ne descend jamais en dessous de 65°C et monte facilement en flèche malgré le fait que la puce ne soit pas utilisée.
Chargement différé : Tout est OK du côté de la température. Le GPU ne tourne pas à pleine puissance mais à un niveau de puissance beaucoup plus bas. Selon la version du système d'exploitation, les capteurs indiquent des températures comprises entre 0°C et 60°C. Bien que cette valeur ne soit pas vraiment réaliste ou fiable, l'ensemble de l'unité reste plus froid au toucher.
Mais "tout va bien" seulement la plupart du temps. De temps en temps, il y a de très rares problèmes de sommeil sur Sierra, et hélas : à chaque fois sur Yosemite.
Constater que le kext doit être chargé pour faire fonctionner la machine mais qu'il est préférable de ne pas le charger (au moins de manière différée) pour mettre la machine en veille : une tentative de kextunload le kext apparemment responsable provoque une panique immédiate. Ce paragraphe est surtout préoccupant dans le cas de Yosemite, mais pas tellement dans le cas de Sierra.
De plus, ce n'est peut-être pas la solution optimale. Dans la configuration actuelle, la gestion thermique a besoin de 1 à 2 minutes après le chargement du kext pour se stabiliser à des niveaux acceptables. D'où l'envie de faire tourner les kexts et de voir ce qui pourrait donner les meilleurs résultats.
Mesures prises jusqu'à présent :
L'un des kexts du pilote graphique dans Sierra doit être chargé au/vers/après le démarrage, automatiquement, mais plus tard.
Ils sont bien sûr interdépendants et sont tous chargés lorsque le système le juge nécessaire dans des circonstances normales.
Mais le système se bloquera au démarrage si le kext en question est chargé trop tôt et le système fonctionnera exactement comme souhaité s'il est chargé plus tard.
Dans ce cas, j'ai confirmé que le fait de le charger manuellement ou en même temps qu'une connexion à l'interface graphique via des crochets fonctionne.
Toutefois, cela signifie que le fait de placer le kext dans le répertoire /System/Library/Extensions ou /Library/Extensions Les résultats de l'accrochage de la botte car ils sont consultés trop tôt.
Ce qui ne fonctionne pas non plus, c'est l'utilisation d'agents ou de démons launchd à l'échelle du système, car ils sont également consultés trop tôt. Les mêmes démons sous les hiérarchies d'utilisateurs n'ont apparemment pas les privilèges nécessaires pour charger un kext.
Alors, où va ce kext de /System/Library/Extensions ? Comment peut-on imposer un délai pour que ce kext ne soit chargé qu'une fois que toutes ses dépendances ascendantes ou descendantes ont été chargées ?
"Quel kext ?" demanderez-vous peut-être. Cette question concerne tous les kexts AMD, chacun devant être testé individuellement.
Il s'agit d'une tentative d'amélioration de cette guide .
Questions
Question principale : Comment peut-on forcer l'un de ces kexts graphiques à un chargement différé ? (Autre que la méthode LoginHook).
Si cela s'avère sous-optimal par rapport à l'objectif fixé, il serait également intéressant, voire préférable, de le savoir :
Existe-t-il d'autres moyens logiciels de maintenir le dGPU désactivé sous les règles thermiques et de gestion de l'énergie du système ? (Le moins d'énergie passe par cette puce inutilisée, le mieux c'est).
Ce cas peut également concerner d'autres extensions du noyau.
