Contexte et explications
Veuillez lire l'intégralité de ce message au moins une fois, du début à la fin, avant d'entreprendre toute action.
Tous Les MacBook Pros de 2011 ont un défaut grave de conception . La gestion thermique et la chaleur générée ainsi que la robustesse des puces graphiques discrètes d'AMD ne sont pas très bien assorties. Apple le savait et a agi comme un typique Soapy Smith qui ne réagit qu'après un outrage. Ce scandale est connu sous le nom de RadeonGate. Seulement menacé d'une action collective en justice, Apple a finalement offert un soi-disant "Programme d'extension des réparations". .
Le programme Repair Extension n'est plus disponible . Le seul réel Le moyen de résoudre ce problème est de remplacer la puce AMD seule. Pas la carte logique. Pas de "re-balling", pas de "reflowing", pas de "baking". Apple a remplacé une puce défaillante par une puce défaillante. Encore et encore. Remplacer uniquement la puce graphique est toujours une procédure matérielle coûteuse pour un ordinateur portable aussi ancien.
Le seul moyen connu - c'est-à-dire : avec un logiciel seul - de faire en sorte qu'un MacBook Pro 2011 (8,2) avec "seulement" une puce graphique AMD défectueuse se rallume de manière presque fiable et démarre dans MacOS et soit tout à fait utilisable. avec une accélération GUI est ce guide ou une variante de celui-ci. La plupart des conseils précédents ont simplement supprimé tous les kexts AMD et cela donne une expérience utilisateur horrible sans aucune accélération de l'interface graphique.
Il est nécessaire de connaître la version exacte de votre système d'exploitation. Le guide suivant sera plus simple pour Yosemite mais suppose El Capitan ou une version plus récente. El Capitan, Sierra et High Sierra ont besoin que SIP (System Integrity Protection) soit désactivé. Sur les systèmes précédents (10.6-10.10), ces étapes sont inutiles.
Important : Ce guide suppose en outre que tous les kexts sont toujours dans leur emplacement par défaut /System/Library/Extensions. Avoir tous les AMD-kexts à cet endroit sauf un est bénéfique pour un fonctionnement "correct". Les hacks précédents dans cette direction ont pu vous demander de bouger, ou pire : supprimer toutes les extensions du noyau AMD*/ATI*. Si c'est le cas : remettez les kexts dans leur emplacement par défaut ou réinstallez un système de votre choix. Avoir la plupart des kexts AMD en place et alors le fait d'avoir le X3000-kext chargé avec un délai permettra de gérer l'alimentation du GPU qui, autrement, brûlera de l'électricité pour rien (et pourrait accélérer la mort thermique finale de la puce en plus de cela). Je le répète : Seul le fichier AMDRadeonX3000.kext
a vraiment été absent au démarrage pour permettre un démarrage réussi, mais tous les autres pilotes AMD (nécessaires) devraient être dans leur emplacement par défaut et le X3000-kext chargé ensuite/retardé pour revenir dans un domaine de gestion de l'énergie et de la température presque raisonnable.
Contournement de la puce graphique discrète
Pour retrouver une certaine accélération de l'affichage, il faudra forcer la machine à ne pas démarrer en mode graphique discret (dGPU) mais directement en mode graphique intégré (iGPU) et à rester dans ce mode.
Le démarrage en mode dGPU est le mode par défaut sur les Macs équipés de deux cartes graphiques commutables. La procédure ci-dessous définit une variable NVRAM qui désactive le dGPU et force le système à utiliser uniquement la carte graphique intégrée d'Intel, même au démarrage.
La variable NVRAM n'est pas documentée mais semble être universellement applicable à tous les Macs avec deux cartes graphiques commutables. Cela signifie qu'elle devrait fonctionner sur les iMacs et les MacBook Pros. Qu'ils aient des puces AMD ou NVIDIA. Les spécificités concernant les pilotes qui pourraient être nécessaires au déplacement ne couvrent qu'AMD dans ce guide. Mais la variable NVRAM contournera la puce graphique discrète dans tous les cas.
Cela vous rendra votre machine, mais vous perdrez certaines fonctionnalités : par exemple, la possibilité de piloter un écran externe à partir du DisplayPort, un peu de performance 3D. Les connexions de données Thunderbolt devraient fonctionner.
Au cas où ce guide échouerait ou ne serait plus souhaité : cette procédure est une pure configuration logicielle et est donc entièrement réversible à tout moment par un simple coup de fil. Réinitialisation de la NVRAM .
La procédure initiale :
Partie 1 : Désactiver SIP, désactiver dGPU, déplacer une extension du noyau
-
Pour repartir de zéro : réinitialiser le SMC et la NVRAM :
l'arrêt, débranchez tout sauf l'alimentation, maintenant maintenez
leftShift + Ctrl + Opt + Power
et de relâcher le tout en même temps ;
-
Maintenant, rallumez et maintenez
Cmd + Opt + p + r en même temps jusqu'à ce que vous entendiez le carillon de démarrage deux fois.
-
Démarrez en mode de récupération pour utilisateur unique en maintenant
Cmd + r + s
-
Désactiver SIP : entrer :
csrutil disable
-
désactiver le dGPU au démarrage en définissant la variable suivante :
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
-
activer le mode de démarrage verbeux :
nvram boot-args="-v"
-
redémarrer en mode utilisateur unique en maintenant
Cmd + s au démarrage
-
mount Partition racine inscriptible
/sbin/mount -uw /
-
créer un répertoire de sauvegarde des kext
mkdir -p /System/Library/Extensions-off
-
ne déplacer qu'UN seul kext offensant :
mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/
-
informer le système de mettre à jour son kextcache :
touch /System/Library/Extensions/
-
redémarrer normalement :
Vous devriez maintenant avoir un affichage accéléré par l'iGPU, mais le système ne sait pas comment gérer l'alimentation de la puce AMD défaillante. (Dans cet état, le GPU tourne toujours au ralenti avec une puissance relativement élevée, consommant pas mal de batterie lorsqu'il est débranché et conduisant à des températures de GPU à partir de 60°C [en moyenne 60-85°C], bien qu'il ne soit pas autrement inutilisé).
Partie 2 : améliorer la gestion thermique et énergétique
Pour améliorer la gestion de l'énergie du GPU désactivé, vous devez soit charger manuellement le kext crucial suivant après botte par :
sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
Si vous avez une application de capteur de température, vous pourriez vouloir l'ouvrir avant de lancer la commande ci-dessus et observer la chute de température
Automatisez cela avec le LoginHook suivant qui sera exécuté après le prochain redémarrage :
sudo mkdir -p /Library/LoginHook
sudo nano /Library/LoginHook/LoadX3000.sh
avec le contenu suivant :
#!/bin/bash
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
pmset -a force gpuswitch 0 # undocumented/experimental
exit 0
alors faites-le *1 exécutable et actif :
sudo chmod a+x /Library/LoginHook/LoadX3000.sh
sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh
*1 : L'utilisation non documentée de cette commande pmset semble améliorer le comportement de sommeil/veille/arrêt. Si ce n'est pas le cas, essayez de ne pas l'utiliser.
Voir l'avertissement ci-dessous. Ce qui suit n'est qu'une spéculation : le sommeil/veille/arrêt peut rester gênant. La théorie ici est que "quelque chose corrompt lentement" ce qui est sauvegardé dans le SMC. Par conséquent, la réinitialisation du SMC et la réapplication du hack variable semblent atténuer la situation pendant un certain temps. (Les solutions permanentes sont les bienvenues !) Comme solution de contournement à court terme, vous devriez essayer d'éviter la "mise en veille par fermeture du couvercle", qui semble causer plus de problèmes que les autres méthodes (menu Apple, raccourci clavier). Les blocages apparents à l'arrêt ne sont généralement que de très longs délais qui finissent par s'arrêter proprement et avec succès.
Un échantillonnage non scientifique suggère que Yosemite est le pire à cet égard et qu'El Capitan et Sierra se comportent beaucoup mieux à cet égard.
Le chargement manuel ou retardé de cette extension cruciale du noyau permet au système de gérer un peu mieux l'alimentation. La batterie sera moins sollicitée et les températures émanant du GPU non utilisé tomberont dans une fourchette nettement inférieure à 50°C (en moyenne entre 15 et 50°C).
Pour une bonne gestion de l'énergie, l'ensemble minimal de kexts chargés sont au démarrage (versions pour 10.12.6, vérifier avec kextstat | grep AMD
) :
com.apple.kext.AMDLegacySupport (1.5.1)
com.apple.kext.AMD6000Controller (1.5.1)
com.apple.kext.AMDSupport (1.5.1)
com.apple.kext.AMDLegacyFramebuffer (1.5.1)
Et si la méthode de chargement ci-dessus réussit, cela devrait apparaître ajouté à la liste :
com.apple.AMDRadeonX3000 (1.5.1)
Une dernière étape consiste à redémarrer une fois de plus dans SingleUserRecovery.
Faites-le avec Cmd + r + s
après que la ligne de commande soit active, entrez :
nvram boot-args="-v agc=0"
et redémarrez normalement.
Cela va refroidir le dGPU un peu plus.
Il est impératif d'émettre cette commande depuis SingleUserRecovery car le système avec SIP activé bloquera vos tentatives de définir cette variable lors du démarrage à partir du volume de démarrage normal, que ce soit en mode de démarrage complet normal ou en mode SingleUser normal. Il est important de noter que cette étape ne peut donc pas être facilement intégrée dans le script force-iGPU.sh script (que vous allez créer dans une minute) et doit être répétée seule après une réinitialisation NVRAM.
Cette dernière étape suppose que SystemIntegretyProtection a été réactivé. Mais si SIP est intentionnellement et définitivement désactivé, alors cette étape puede être intégré dans le force-iGPU.sh script ci-dessus.
Mais comme j'avais l'intention de désactiver le SIP en permanence et qu'il a été réactivé sans que je m'en aperçoive, le fait que le SIP reste désactivé n'est peut-être pas la meilleure approche. L'effacement de la NVRAM, où sont stockés les paramètres du SIP, pourrait être une de ces perturbations imprévues.
Mesures préventives pour une utilisation future
Il y a deux autres mises en garde à connaître : C'est réversible lorsque le SMC/NVRAM est réinitialisé. Dans ce cas, la variable GPU-power-pref de la NVRAM peut ou même doit être réactivée pour forcer l'utilisation de l'iGPU au démarrage.
Puisque cela peut se produire assez facilement (et est souvent recommandé de manière erronée bien trop souvent par rapport à son utilité réelle), vous devriez probablement vous préparer à un tel scénario et créer un simple script pour accélérer considérablement le processus et également rendre la saisie de la variable nécessaire beaucoup moins sujette aux erreurs :
sudo nano /force-iGPU-boot.sh
- Entrez le contenu suivant dans ce fichier :
#/bin/sh
sudo nvram boot-args="-v"
sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
exit 0
- Maintenant, rendez cet exécutable :
sudo chmod a+x /force-iGPU-boot.sh
À l'avenir, lorsque la SMC/PRAM/NVRAM sera réinitialisée aux valeurs par défaut, il sera désormais possible de démarrer en mode SingleUser :
Cmd + s
- Et après avoir monté votre volume de démarrage en lecture-écriture pour exécuter cette seule ligne :
sh /force-iGPU-boot.sh
Rappelez-vous que la variable agc est maintenant également effacée. (Voir ci-dessus)
Veillez également à redéfinir le volume de démarrage par défaut dans Préférences Système > Disque de démarrage.
Partie 3 : Gérer les mises à jour d'Apple
Cette installation a maintenant un kext dans un endroit que les installateurs d'Apple n'attendent pas. C'est pourquoi dans ce guide SIP n'a pas été réactivé. Si une mise à jour qui contient des changements aux pilotes AMD est sur le point d'avoir lieu, il est conseillé de remettre le AMDRadeonX3000.kext à son emplacement par défaut. avant le processus de mise à jour. Sinon, le programme de mise à jour écrit au moins un autre kext d'une version différente à son emplacement par défaut ou, au pire, vous vous retrouvez dans un état indéfini de pilotes partiellement non compatibles.
Après toute mise à jour du système, le dossier /System/Library/Extensions doit être vérifié pour trouver le kext incriminé. Sa présence dans ce dossier entraînera, par exemple, un blocage du démarrage sur Yosemite et Sierra, une boucle de démarrage en surchauffe dans High Sierra.
Mise à niveau vers High Sierra 10.13 : avec ce hack en place est presque direct : Malgré l'application d'une mise à jour du firmware, le processus d'installation ne devrait pas toucher à la variable NVRAM. Le processus d'installation n'utilise pas non plus une puce AMD entièrement accélérée, mais une accélération de base qui ne pose pas de problème pour ce piratage. Cependant, comme indiqué dans le paragraphe ci-dessus, le premier démarrage d'un système dont l'installation est terminée mais qui est sur le point de commencer le processus de configuration produira une boucle de démarrage induite par la chaleur ou un crash. L'extension du noyau incriminée doit être déplacée à nouveau comme décrit ci-dessus. (En commençant par l'étape 3) Après avoir déplacé le kext, tout devrait bien se passer.
Avis important concernant les récentes mises à jour d'Apple :
Les dernières mises à jour pour (High) Sierra rupture la machine à nouveau. Il met à jour le firmware, RecoveryPartition, semble désactiver la possibilité de démarrer en SingleUserRecoveryMode
Et pour couronner le tout, il installe - même avec le DeltaUpdate - un AMDRadeonX3000.kext fonctionnel !
Sans préparation et avec seulement la machine à portée de main, vous serez un peu bloqué.
Si SingleUserRecoveryMode a disparu pour de bon, utilisez le RecoveryMode normal. Les résultats sont les mêmes, le démarrage est juste un peu plus lent. La procédure ci-dessus est toujours valable et plus rapide pour toutes les versions précédentes de Mac OS X/MacOS.
Si vous mettez à jour à 10.13.6, ou plus tard :
Remplacer les instructions pour le SingleUserRecoveryMode ( Command + r + s ) avec le RecoveryMode normal ( Command + r ) et désactiver le SIP via le terminal ( Exemple pour ce cas d'utilisation précis ).
Au cas où vous trouveriez que même le RecoveryMode normal ne fonctionne pas comme prévu :
Solutions de contournement pour l'impossibilité de désactiver SIP avec SingleUserRecovery :
-
Tout d'abord, démarrez en mode de récupération mono-utilisateur. Les modifications de csrutil ne sont pas autorisées dans ce mode, mais vous pouvez définir la propriété gpu-power-prefs nvram. Cela aidera à redémarrer la machine en mode récupération. Ensuite, vous devez remplacer les instructions pour SingleUserRecoveryMode ( Command + r + s ) avec le RecoveryMode normal ( Command + r ) et désactiver le SIP via le terminal ( Exemple pour ce cas d'utilisation ).
-
Avant une mise à jour, préparez un volume amorçable. Cela peut être un disque externe ou une clé. Toute version permettant de démarrer la machine fera l'affaire. Un tel disque peut être créé sur un autre Mac.
N'oubliez pas que sur le disque externe, le fichier AMDRadeonX3000.kext doit également être (re)déplacé. Essayez de démarrer à partir de ce disque. Seulement si cela fonctionne comme prévu et que vous pouvez monter votre disque interne avec : redémarrez depuis votre disque interne et procédez à la mise à jour de votre disque interne/système vers 10.13.6.
Après que la mise à jour soit presque terminée, un redémarrage sera suspendu. Forcez un arrêt et un redémarrage à partir de votre disque externe. Montez le disque interne et déplacez le Radeon.kext. Le SIP ne protège que le système démarré.
-
Suggéré quelque part en ligne, mais vraiment une supposition désespérée et non testée : au lieu de SingleUserRecoveryMode avec Cmdrs vous pouvez essayer InternetRecoverySingleUserMode CmdOptrs . Alternativement, cela pourrait valoir la peine d'essayer de voir si le SafeRecoveryMode fonctionne. CmdShiftr .
Le mode de récupération graphique peut également ne pas fonctionner, comme ce fut le cas pour moi. Cependant, dans la dernière version de High Sierra, il est toujours possible de démarrer en mode de récupération mono-utilisateur. Il faut juste un bon timing. L'astuce consiste à activer d'abord le mode de récupération en appuyant sur cmd+R et, immédiatement après, la commande cmd+S pour le mode utilisateur unique. Le moment exact doit être déterminé par l'utilisateur. Si cmd+R+S sont appuyés en même temps, seul le mode mono-utilisateur sera activé. Si cmd+R est pressé en premier et cmd+S est pressé trop tard, le mode de récupération graphique est chargé. - TAKeanice
Les touches de luminosité de l'écran ne fonctionnent pas dans High Sierra ou Mojave ?
Apple a modifié la façon dont les événements clavier pour la modification de la luminosité de l'écran sont traités dans High Sierra. Avec cette modification en place, les touches pourrait être sans fonction. Si c'est le cas : Une raison de plus de rester avec Sierra.
Mais vous pouvez aussi recourir à une autre solution logicielle. Des applications prêtes à l'emploi ou des extensions :
Version recommandée du système d'exploitation
Ce hack a été développé avec des machines fonctionnant sous Yosemite (10.10) à Sierra (10.12). Il fonctionne très bien sur ces machines.
High Sierra
High Sierra (10.13) fonctionne bien aussi. Et c'est la dernière version "officiellement entièrement prise en charge par Apple". Enfin, anciennement supportée. Cela fonctionne bien avec ce hack, et vous pouvez réactiver le SIP. Pour obtenir davantage de mises à jour de sécurité, vous devez aller plus loin :
Mojave
Avec Mojave (10.14), le processus d'installation n'est absolument pas pris en charge par Apple et devient beaucoup plus compliqué :
- Vous devez installer High Sierra une fois, pour obtenir les mises à jour du micrologiciel d'Apple pour la prise en charge du démarrage APFS. (Alternative : une partie du guide du patch dosdude1 .)
- Vous devez suivre les procédures requises par le dosdude1 patcher.
- Cela signifie faire confiance à "ce type".
- Beaucoup de redémarrages sont nécessaires.
- Les paramètres NVRAM sont apparemment toujours perdus dans le processus - réappliquez comme décrit ci-dessus une fois que la procédure de patch/installation est terminée. (Si vous obtenez des couleurs étranges, par exemple dans les onglets de Safari après la mise à niveau vers 10.14 : AMD est actif , vérifiez via System Report)
- Avertissement : ne pas suivez la recommandation de dosdude1 de désactiver le GPU ! - ; Utilisez celle du dessus, comme d'habitude (La version de dosdude1 tourne plus vite ). Parce que, une fois que vous acceptez ce Franken-statut de 'support' d'Apple, cet OS patché, SIP maintenant désactivé par nécessité ( !), plus les inconvénients habituels de ce hack (et par exemple les nouvelles versions de Safari qui tuent vos extensions favorites )
-
Vous devrez garder autour de vous un volume externe /USB-Stick with the patched installer, otherwise your machine may become unbootable by updates from Apple
- Mojave est actuellement le meilleur OS fonctionnel (IMO) pour cette machine. Essayez-le.
Pour éviter les plantages, les pannes et les boucles de démarrage - qui ne sont jamais une bonne idée pour votre système de fichiers - lors d'une nouvelle installation ou d'une mise à jour : assurez-vous de surveiller le processus d'installation et démarrez toujours en mode sans échec (gardez le bouton Shift appuyé pendant les démarrages jusqu'à ce que le kext soit déplacé dans un endroit sûr -- l'installation devrait se dérouler sans problème en SafeMode.
Remarques de clôture et recommandations
En outre, cet ordinateur portable surchauffe, quoi que vous fassiez. Le système de refroidissement est inadéquat et le grand nombre de puces AMD défaillantes en est la preuve.
Pour prolonger la durée de vie de cette machine désormais piratée, il est conseillé de s'abstenir de soulever des charges très lourdes pendant des périodes prolongées. Suivez scrupuleusement les recommandations habituelles pour les ordinateurs portables : utilisez-les sur des surfaces dures, gardez les ventilateurs et les ailettes à l'intérieur propres. L'utilisation d'un logiciel de contrôle du ventilateur avec des paramètres relativement agressifs devrait également être utile : par exemple smcFanControl MacsFanControl, ou TGPro (tous deux commerciaux).
Avis de non-responsabilité : Cette procédure n'est pas une solution miracle. L'état d'échec de ces puces n'est pas prévisible à 100%. Très peu d'utilisateurs ont des problèmes même avec ce hack en place : il peut y avoir des problèmes de redémarrage, d'endormissement ou de réveil, la plupart d'entre eux venant d'utilisateurs avec Yosemite, le moins de problème semble être sur Sierra. Dans ces cas, il semble parfois nécessaire de ne pas utiliser le AMDRadeonX3000.kext, et donc pas non plus le LoginHook de la partie 3. (Mais voir la note supplémentaire sous *1 ci-dessus.) Les utilisateurs de High Sierra rapportent des problèmes avec le réglage du rétro-éclairage de leurs écrans.
Dans certains cas, même avec toutes ces mesures en place, il semble que le port Thunderbolt, qui fonctionne encore, pose des problèmes si des périphériques sont connectés et actifs lorsque la machine se met en veille. Après cela, tout cycle de sommeil ultérieur peut être affecté et une réinitialisation de la NVRAM avec la danse de réglage des variables décrites ci-dessus sera à nouveau nécessaire. Dans ce cas, il est conseillé d'empêcher la mise en veille de la machine ou de débrancher tout matériel sur le port Thunderbolt avant de laisser la machine se mettre en veille.
Dans le respect des restrictions énoncées au début de cette réponse : La plupart des utilisateurs rapportent un succès total.
Mods/hacks matériels
Plusieurs moyens sont disponibles aujourd'hui, certains mauvais, d'autres bons.
Mauvaise solution : Une modification matérielle très bon marché est disponible à/auprès de RealMacMods : Bien qu'ils utilisent une manière relativement compliquée de régler la variable EFI nécessaire avec linux, ce qui suit a l'avantage de couper la tension du noyau au dGPU complètement en enlevant juste une petite résistance ! (Photos sur le lien)
Lors de ce redémarrage, il est essentiel que vous démarriez une fois en mode sans échec (maintenez la touche Maj pendant tout le démarrage), puis que vous choisissiez d'arrêter (et non de redémarrer) dans le menu.
Faites ce démarrage sûr avec la résistance R8911 en place. Sans ce SAFE BOOT, les étapes suivantes peuvent ne pas fonctionner.
Ne faites plus de bottes jusqu'à ce que vous ayez terminé les étapes suivantes.
Le démarrage sécurisé efface les préférences GPU au niveau du système d'exploitation, qui peuvent interférer avec le processus suivant.
Ainsi, votre MacBook Pro cessera de basculer automatiquement sur la Radeon, mais celle-ci continuera à consommer de l'énergie, à générer de la chaleur et à être visible pour le système d'exploitation.
Nous avons découvert que le simple fait de retirer une résistance résout ce problème.
La résistance peut également être remplacée par un interrupteur, au cas où vous auriez besoin de rallumer votre radeon pour une raison quelconque.
L'emplacement de cette résistance varie selon les modèles de cartes logiques.
La résistance en question est R8911 sur le 17 MBP et R8911 sur le 15 MBP une résistance de 1 Ohm qui fournit un chemin de courant au convertisseur CC-CC ISL6263C.
Cette résistance contrôle l'alimentation du régulateur de tension qui fournit la tension de base au GPU Radeon. En d'autres termes, sans tension centrale, pas de GPU. Vous trouverez la résistance juste à droite d'un ventilateur de refroidissement (dans l'orientation ci-dessus). Elle se trouve près de la puce du convertisseur de tension ISL. C'est cette puce que nous allons désactiver.
Il suffit de l'enlever. La méthode préférée est une station de refusion professionnelle, mais un fer à repasser et une main ferme vous permettront d'y arriver. Si vous avez utilisé du flux pour l'enlever (ce n'est pas nécessaire), assurez-vous de nettoyer avec un peu d'alcool ou un autre solvant approprié.
C'est à peu près tout. Au prochain démarrage, vous remarquerez que le problème de défaut du GPU a disparu et que le GPU AMD n'apparaît plus comme matériel installé.
Je ne l'ai pas testé mais cela devrait éliminer tout besoin de s'occuper des kexts et aussi résoudre tous les problèmes concernant la veille, le réveil, l'hibernation, le redémarrage, etc.
Mise en garde concernant cette méthode : comme elle semble également dépendre de la définition de cette variable NVRAM, il est probable que le système de gestion de l'information de l'entreprise n'ait pas été modifié. absolument indispensable de disposer d'une méthode entièrement automatisée pour définir cette variable sans aucune intervention de l'utilisateur. (Comme une clé linux qui effectue les changements nécessaires). Sinon, une réinitialisation de la NVRAM pourrait pratiquement briquer la machine. Le fournisseur suggère de se protéger des réinitialisations accidentelles de la NVRAM par un mot de passe et, si une réinitialisation est effectuée, de l'appeler pour une "procédure".
Si vous êtes mordu par cette méthode et que vous n'obtenez qu'un écran noir, il semble possible d'accéder à distance à la machine à l'aide de VNC ou de ssh. si ceux-ci sont configurés au préalable, ce n'est peut-être pas une si mauvaise option après tout, puisque la variable nvram peut être définie de cette façon. Rappelez-vous : Histoire internet non testée.
Une solution matérielle permanente, fiable et bon marché !
Dosdude1 a trouvé une solution qui semble être le Saint Graal pour ce problème : Désactiver définitivement le GPU dédié du MacBook Pro 15"/17" 2011 - contournement du circuit gMux.
- L'option A, qui sera détaillée ci-dessous, consiste à câbler les lignes de sortie LVDS de la carte graphique intégrée directement aux lignes de connexion de l'écran.
- L'option B serait de reprogrammer le circuit intégré gMux (qui est simplement un microcontrôleur Lattice LFXP2), avec un firmware personnalisé pour désactiver la fonctionnalité de commutation GPU. Je pourrais expérimenter cela à l'avenir, mais cela nécessite un matériel spécial que je n'ai pas. Ce serait, bien sûr, la solution optimale, cependant.
C'est presque facile. Tout ce qu'il faut, c'est différentes longueurs de fil . Pour avoir un aperçu : sur youtube.
La "mauvaise solution" décrite ci-dessus est maintenant transformée en une solution matérielle presque professionnelle et préfabriquée, ce qui élimine le caractère "mauvais" de cette approche :
Tirésias (le tueur de GPU) : Le Tirésias est une petite carte qui peut être soudée sur la carte mère des modèles MacBook Pro 15 pouces ou 17 pouces 2011 (Early ou Late).
Il s'agit de tous les modèles équipés de la carte mère 820-2914-A, 820-2914-B, 820-2915-A ou 820-2915-B.
La carte 820-2914 et 820-2915 possède deux GPU. Le GPU interne (Intel) qui fait partie de la PCH, et un GPU externe (discret) AMD. C'est le GPU externe qui tombe en panne dans "un petit pourcentage de systèmes MacBook Pro" (langage Apple pour : "très nombreux"). Tirésias écrit la variable nvram 'gpu-power-prefs' dans la ROM pour que le Mac n'utilise plus le GPU externe (discret) AMD (mort). Si l'utilisateur efface la NVRAM (PRAM), il n'y a aucun problème car le Tirésias réécrit l'enregistrement et le Mac fonctionne à nouveau.
Cela en fait la solution idéale pour ramener à la vie un 820-2914 ou 820-2915 dont le GPU est mort. L'installation est facile (pas de fils à souder). Vous devrez monter une toute petite carte sur la carte mère. Un technicien expérimenté peut le faire en quelques minutes. A part cela, le R8911 doit être retiré pour couper l'alimentation du GPU mort. Cela permet d'économiser de l'énergie, de générer moins de chaleur et de préserver l'autonomie de la batterie. Le retrait du R8911 empêche également le Mac d'être perturbé par le GPU mort, car même si le GPU est éteint, il essaiera toujours de communiquer avec le GPU mort. Selon les contacts internes du GPU qui sont rompus, cela peut perturber ou même faire planter le Mac.
Mac OS X 10.13 High Sierra est également pris en charge. Pour résoudre le problème du rétro-éclairage qui ne se rallume pas après la mise en veille, retirez également le R9704 et connectez la broche 2 du R9704 à la broche 1 du C9711.
OS X 10.6 - 10.12 (Sierra)
Le curseur de rétroéclairage (dans les préférences système) et les touches de rétroéclairage (F1 et F2) fonctionnent. La mise en veille du système fonctionne. La sortie vidéo sur le port Thunderbolt ne fonctionne pas, mais toutes les autres fonctions du port Thunderbolt fonctionnent.
OS X 10.13 (High Sierra)
Pour autant que nous le sachions, la version 10.13 (High Sierra) n'offre aucun avantage par rapport à la version 10.12 (Sierra). Apple a totalement refait les pilotes vidéo dans High Sierra, et il semble que cela ait été un véritable gâchis. Les commandes de rétroéclairage ne fonctionnent pas. Pire encore, lorsque l'ordinateur sort de sa veille, le rétroéclairage ne se rallume pas du tout.
Pour résoudre le problème du rétro-éclairage qui ne s'allume pas après la mise en veille, enlevez R9704 et connectez la broche 2 de R9704 à la broche 1 de C9711. Cela règle le rétro-éclairage sur la luminosité maximale. L'inconvénient est qu'avec cette modification, la luminosité sera également à fond avec les anciens systèmes d'exploitation.
Tirésias pour 820-2915 (15-Inch) Quantité un (1) Frais de port inclus (monde entier) 60 EURO.
Mise à jour pour une solution logicielle à guichet unique
Ce piratage semble avoir été lancé partiellement dans une application liée au piratage du matériel ! D'un côté, cette application est plus universelle que la solution ci-dessus, car elle semble gérer aussi les cartes NVidia, c'est-à-dire qu'elle permet de désactiver tous les CPU discrets de tous les Macs.
Hélas, cette application de dosdude1 n'est pas bien documentée. Le lisez-moi dit qu'elle définit la variable NVRAM, déplace tous les pilotes d'accélération graphique, puis installer un launchdaemon pour gérer les mises à jour et s'assurer que la variable reste activée.
Non testé et non approuvé - si vous avez déjà suivi la procédure décrite ci-dessus !
Mais si l'astuce ci-dessus n'a pas fonctionné pour vous ou si elle vous semble trop intimidante, vous pouvez essayer ceci :
dosdude1 : D'autres logiciels non documentés que j'ai écrits sont stockés ici : MacBook Pro dGPU Disabler.zip
Il faudrait peut-être revoir la procédure ci-dessus, car l'application semble manquer d'améliorer la partie gestion thermique (si vous modifiez le matériel en enlevant le transistor, cela devient de l'humeur : mix and match).
Si quelqu'un teste ce système, merci de donner un retour d'information ici via les commentaires ou une modification.
Mise à jour 2019 : solution 20$. qui utilise un ordinateur Windows 64bit et un programmateur FPGA Lattice HW-USBN-2A ICSP pour appliquer un firmware personnalisé au circuit intégré gMux. Dosdude1 affirme qu'il s'agit d'une solution "parfaite", ce qui signifie que même sous HighSierra et Mojave, l'autonomie, la température, le contrôle de la luminosité et la veille fonctionnent comme prévu. L'utilisation de cette solution est permanente et rend tout ce qui précède obsolète.
Mais cette nouvelle solution n'est pas gratuite et nécessite du matériel sous la forme d'un PC Windows et du programmateur) ; ainsi que de souder actuellement quelques fils de manière temporaire à la carte logique).
[Mise à jour : juin 2020] : Ce gMUX Bypass avec contrôle natif de la luminosité est une version moins chère (opensource) du hack matériel Dosdude1. GitHub : gMUXBypass
1 votes
Voir : Programme d'extension de réparation de MacBook Pro pour les problèmes de vidéo .
1 votes
@klanomath Oui, c'est le problème. C'est arrivé à mon ancien MBP aussi (juste un écran verdâtre plutôt que gris).