Contexte et explications
Veuillez lire l'intégralité de cet article au moins une fois du début à la fin avant de prendre toute mesure.
Tous les MacBook Pros de 2011 présentent un grave défaut de conception . La gestion thermique et la chaleur générée ainsi que la robustesse des puces graphiques AMD discrètes ne correspondent pas très bien. Apple le savait et agissait comme un Soapy Smith typique , ne réagissant à cela qu'après un scandale. Ce scandale a pris le nom de RadeonGate. Ce n'est qu'avec un recours collectif menacé que Apple a finalement été contraint d'offrir un soi-disant "programme d'extension de réparation" .
Le programme Apple Repair Extension n'est plus disponible . Le seul véritable moyen de résoudre ce problème est de remplacer la puce AMD seule. Pas la carte mère. Pas de "re-balling", pas de "reflowing", pas de "baking". Apple a remplacé une puce défectueuse par une puce défaillante. Maintes et maintes fois. Seul le remplacement de la puce graphique est toujours une procédure matérielle coûteuse pour un tel ordinateur portable vintage.
Le seul moyen connu - c'est-à-dire avec un logiciel seul - pour obtenir un MacBook Pro 2011 (8,2) avec `` seulement '' une puce graphique AMD défaillante pour se réactiver de manière presque fiable et démarrer sous macOS et être tout à fait utilisable avec une interface graphique accélérée est ce guide ou une variante de celui-ci. La plupart des astuces précédentes viennent de supprimer tous les AMD-kexts et cela se traduit par une expérience utilisateur horrible sans aucune accélération de l'interface graphique.
Il est nécessaire de connaître votre version exacte du système d'exploitation. Le guide suivant sera plus simple pour Yosemite mais suppose El Capitan ou plus récent. El Capitan, Sierra et High Sierra doivent désactiver la protection SIP (System Integrity Protection). Sur les systèmes précédents (10.6–10.10), ces étapes ne sont pas nécessaires.
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, sauf un, est bénéfique pour un fonctionnement «correct». Les hacks précédents dans cette direction peuvent vous avoir demandé de bouger, ou pire: supprimer toutes les extensions du noyau AMD * / ATI *. Si tel 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 ensuite charger le X3000-kext avec un retard permettra la gestion de l'alimentation du GPU qui autrement brûlerait l'électricité pour rien (et pourrait accélérer la mort thermique finale de la puce en plus de cela). Pour réitérer: Seul le dossier a AMDRadeonX3000.kext
vraiment été absent au démarrage pour permettre un démarrage réussi, mais tous les autres pilotes AMD (nécessaires) doivent être dans leur emplacement par défaut et le X3000-kext chargé ensuite / retardé pour revenir dans un domaine de gestion de l'alimentation et de la température presque sensible.
Contournement de la puce graphique discrète
Pour récupérer une accélération d'affichage, il sera nécessaire de forcer la machine à ne pas démarrer en graphiques discrets (dGPU) mais directement en graphiques intégrés (iGPU) et de rester dans ce mode.
Le démarrage en mode dGPU est la valeur par défaut sur les Mac avec deux cartes graphiques commutables. La procédure ci-dessous définira une variable NVRAM qui désactive le dGPU et force le système à utiliser uniquement les graphiques Intel intégrés même lors du démarrage.
La variable NVRAM n'est pas documentée mais semble être universellement applicable à tous les Mac avec deux cartes graphiques commutables. Cela signifie qu'il devrait fonctionner sur les iMacs et les MacBook Pros. Qu'ils aient des puces AMD ou NVIDIA. Les détails sur les pilotes qui pourraient être nécessaires pour déplacer ne couvrent que 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 performances 3D. Les connexions de données Thunderbolt devraient fonctionner.
Si ce guide échoue ou n'est plus souhaité: cette procédure est une configuration logicielle pure et donc entièrement réversible à tout moment avec une simple réinitialisation de la NVRAM .
La procédure initiale:
Partie 1: Désactiver SIP, désactiver dGPU, déplacer une extension du noyau
Pour commencer à partir d'une table rase: réinitialiser SMC et NVRAM:
arrêt, débrancher tout sauf l'alimentation, maintenant tenir
leftShift+ Ctrl+ Opt+ Power
et relâchez tous en même temps;
Maintenant, rallumez et maintenez
Cmd+ Opt+ p+ r
en même temps jusqu'à ce que vous entendiez deux fois le carillon de démarrage.
Démarrez dans Single User Recovery en maintenant
Cmd+ r+s
Désactiver SIP: entrez:
csrutil disable
désactivez 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 détaillé:
nvram boot-args="-v"
redémarrer en mode mono-utilisateur en maintenant
Cmd+ s
au démarrage
monter la partition racine accessible en écriture
/sbin/mount -uw /
créer un répertoire de sauvegarde kext
mkdir -p /System/Library/Extensions-off
éloignez seulement UN 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é 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 de 60 ° C vers le haut [en moyenne 60-85 ° C], bien qu'il ne soit utilisé pour rien par le système .)
Partie 2: améliorer la gestion thermique et électrique
Pour une meilleure gestion de l'alimentation du GPU désactivé, vous devez soit charger manuellement le seul kext crucial après le démarrage en:
sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
Si vous avez une application de capteur de température, vous voudrez peut-être l'ouvrir avant d'émettre la commande ci-dessus et regarder les températures chuter…
Automatisez ceci 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
puis rendez-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 sommeil / réveil / arrêt. Si ce n'est pas le cas, essayez de le laisser de côté.
Voir la clause de non-responsabilité ci-dessous. Ce qui suit n'est qu'une spéculation: le sommeil / réveil / arrêt peut rester gênant. La théorie ici est que "quelque chose corrompt lentement" ce qui est enregistré 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. (Solutions permanentes pour cet accueil!) Comme solutions de contournement de courte durée, vous voudrez peut-être essayer d'éviter le "sommeil de fermeture du couvercle", qui semble poser plus de problèmes que d'autres méthodes (Apple-Menu, Keyboard-Shorcut). Les blocages apparents à l'arrêt ne sont généralement que de très longs retards qui s'arrêteront, éventuellement, proprement et avec succès.
Un échantillonnage non scientifique suggère que Yosemite est pire pour cela et El Capitan et Sierra se sont beaucoup mieux comportés à cet égard.
Le chargement manuel ou différé de cette extension essentielle du noyau permet au système de gérer un peu mieux la gestion de l'alimentation. La batterie sera moins utilisée et les températures émanant du GPU inutilisé tomberont dans une plage nettement inférieure à 50 ° C (en moyenne entre 15 et 50 ° C).
Pour une bonne gestion de l'alimentation, l'ensemble minimal de kexts chargés est au démarrage (versions pour 10.12.6, vérifiez 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 a réussi, cela devrait apparaître ajouté à la liste:
com.apple.AMDRadeonX3000 (1.5.1)
Une dernière étape consiste à redémarrer à nouveau dans SingleUserRecovery
Faites cela avec Cmd+ r+ une s
fois la ligne de commande activée, entrez:
nvram boot-args="-v agc=0"
et redémarrez normalement.
Cela refroidira un peu plus le dGPU.
Il est impératif d'émettre cette commande à partir de 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 SingleUser normal. Il est important de noter que cette étape ne peut pas être facilement intégrée dans le script force-iGPU.sh (que vous créerez 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é, cette étape peut être intégrée dans le script force-iGPU.sh ci-dessus.
Mais étant donné que j'avais l'intention de garder SIP éteint de façon permanente et qu'il a été réactivé sans que je ne m'en rende compte, se fier à SIP rester "éteint" pourrait ne pas être la meilleure approche. L'effacement de la NVRAM, où les paramètres SIP sont stockés, pourrait être une de ces perturbations imprévues.
Mesures préventives pour une utilisation future
Il y a deux autres mises en garde à savoir: Ceci est réversible lorsque le SMC / NVRAM est réinitialisé. Si cela se produit, la variable NVRAM GPU-power-pref peut ou même doit être définie à nouveau pour forcer l'utilisation de l'iGPU à partir du démarrage.
Étant donné que cela peut se produire assez facilement (et est souvent recommandé à tort trop de fois qu'il n'est réellement utile), vous devez probablement vous préparer à un tel scénario et créer un script simple pour accélérer considérablement le processus et rendre la saisie de la variable nécessaire beaucoup moins sujet 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
- Rendez maintenant 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 dans SingleUser avec:
Cmd+s
- Et après avoir monté votre volume de démarrage en lecture-écriture pour exécuter uniquement cette seule ligne:
sh /force-iGPU-boot.sh
N'oubliez pas que la variable agc est désormais également effacée. (Voir ci-dessus)
Assurez-vous également de définir à nouveau le volume de démarrage par défaut dans Préférences Système> Disque de démarrage.
Partie 3: Gestion des mises à jour d'Apple
Cette configuration a maintenant un kext dans un endroit auquel les installateurs d'Apple ne s'attendent pas. C'est pourquoi, dans ce guide, SIP n'a pas été réactivé. Si une mise à jour contenant des modifications des pilotes AMD est sur le point d'avoir lieu, il est conseillé de ramener 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 avec un état indéfini de pilotes partiellement non correspondants.
Après toute mise à jour du système, le dossier / System / Library / Extensions doit être vérifié pour le kext incriminé. Sa présence entraînera par exemple un blocage de démarrage sur Yosemite et Sierra, une boucle de démarrage surchauffée dans High Sierra.
Mise à niveau vers High Sierra 10.13: avec ce hack en place est presque simple: malgré l'application d'une mise à jour du firmware, le processus d'installation ne doit pas toucher la variable NVRAM. Le processus d'installation n'utilise pas non plus de puce AMD entièrement accélérée mais une accélération de base qui ne pose pas de problème concernant ce hack. Cependant, comme indiqué dans le paragraphe ci-dessus, le premier démarrage dans un système dont l'installation est terminée mais sur le point de démarrer le processus de configuration produira une boucle de démarrage induite par la chaleur / le crash. L'extension du noyau incriminée doit être déplacée à nouveau comme décrit ci-dessus. (À partir de l'étape 3) Après avoir déplacé le kext, tout va bien.
Mises à jour récentes d'Apple: ne mettez pas à jour avant d'avoir lu ce qui suit.
Jusqu'à nouvel ordre:
les mises à jour récentes cassent à nouveau la machine. Il met à jour le firmware, RecoveryPartition, semble désactiver la possibilité de démarrer dans SingleUserRecoveryMode
et pour couronner le tout, il installe - même avec DeltaUpdate - un AMDRadeonX3000.kext fonctionnel!
Sans préparation et avec juste la machine à portée de main, vous serez un peu coincé.
Dans le cas où SingleUserRecoveryMode a disparu définitivement, utilisez RecoveryMode normal. Les résultats sont les mêmes, il est juste un peu plus lent à démarrer: la procédure ci-dessus est toujours valide et plus rapide pour toutes les versions précédentes de Mac OS X / macOS.
Mais si vous effectuez une mise à jour vers 10.13.6, ou version ultérieure:
vous devez alors remplacer les instructions pour SingleUserRecoveryMode ( Command+ r+ s) par RecoveryMode normal ( Command+ r) et désactiver SIP via Terminal ( exemple pour ce cas d'utilisation précis ).
Dans le cas où vous appartenez à ceux où même RecoveryMode normal ne fonctionne pas comme prévu:
Solutions de contournement pour l'incapacité de désactiver SIP avec SingleUserRecovery:
Tout d'abord, démarrez en mode de récupération mono-utilisateur. Les modifications csrutil ne sont pas autorisées dans ce mode, mais peuvent définir la propriété nvram gpu-power-prefs. Cela vous aidera à redémarrer la machine en mode de récupération. Ensuite, vous devez remplacer les instructions pour SingleUserRecoveryMode ( Command+ r+ s) par RecoveryMode normal ( Command+ r) et désactiver SIP via le terminal ( exemple pour ce cas d'utilisation précis ).
Avant de mettre à jour, préparez un volume de démarrage. Cela peut être un disque externe ou un bâton. Toute version qui démarre la machine ira bien. Un tel lecteur peut être créé sur un autre Mac.
Gardez à l'esprit que sur le disque externe, l'AMDRadeonX3000.kext doit également être (re) déplacé. Essayez de démarrer à partir de ce lecteur. Seulement si cela fonctionne comme prévu et que vous pouvez monter votre lecteur interne avec lui: redémarrez à partir de votre lecteur interne et procédez à la mise à jour de votre lecteur / système interne vers 10.13.6.
Une fois la mise à jour presque terminée, un redémarrage se bloque. Forcer un arrêt et redémarrer à partir de votre disque externe. Montez le lecteur interne et déplacez le Radeon.kext. SIP protège uniquement 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 Cmdrsvous, essayez InternetRecoverySingleUserMode CmdOptrs. Alternativement, il pourrait être utile d'essayer de voir si SafeRecoveryMode fonctionne CmdShiftr.
Le mode de récupération graphique peut ne pas fonctionner aussi, comme il l'a fait 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 avoir reconnu la commande cmd + S pour le mode mono-utilisateur. Le moment exact doit être déterminé par l'utilisateur. Si vous appuyez simultanément sur cmd + R + S, seul le mode utilisateur unique sera activé. Si vous appuyez d'abord sur cmd + R et sur cmd + S 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?
Apple a changé la façon dont les événements de clavier pour modifier la luminosité de l'écran sont gérés dans High Sierra. Avec ce hack ou les mods matériels ci-dessous en place, les touches seront sans fonction. Une raison de plus de rester avec Sierra. Mais avec ce hack, vous pourriez également recourir à une autre solution logicielle. En plus de pirater votre propre solution AppleScript, vous voudrez peut-être essayer des applications ou des applications prêtes à l'emploi.
Par exemple, Brightness Slider sur l'AppStore propose des raccourcis clavier personnalisables.
Pour éviter ces plantages / blocages / 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 à niveau: assurez-vous de garder le processus d'installation et de toujours démarrer en SafeMode (maintenez Shiftenfoncé pendant les démarrages jusqu'à ce que le kext est déplacé dans un endroit sûr –– l'installation devrait se dérouler très bien dans SafeMode.
Remarques de clôture et recommandations
De plus: 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 sont la preuve.
Pour prolonger la durée de vie de cette machine désormais piratée, il est conseillé de s'abstenir de soulever de lourdes charges sur des périodes de temps prolongées. Suivez strictement les recommandations habituelles pour les ordinateurs portables: utilisez sur des surfaces dures, gardez les ventilateurs et les ailettes à l'intérieur propres. L'utilisation de tout logiciel fancontrol avec des paramètres relativement agressifs devrait également aider: comme smcFanControl , MacsFanControl ou TGPro (tous deux commerciaux).
Avis de non-responsabilité: toute cette procédure n'est pas une solution miracle. L'état de défaillance 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, de sommeil ou de réveil correctement, la plupart provenant d'utilisateurs de Yosemite, le moindre problème semble être sur Sierra. Dans ces cas, il semble parfois nécessaire de ne pas utiliser AMDRadeonX3000.kext, et donc pas non plus le LoginHook de la partie 3. (Mais voir la note supplémentaire sous * 1 ci-dessus.) Un nombre disproportionné d'utilisateurs sur High Sierra signalent des problèmes avec leurs écrans réglage du rétroéclairage. Donc, actuellement, le point idéal pour le choix du système d'exploitation est à mon avis 10.12 Sierra.
Dans certains cas, même avec toutes ces mesures en place, il semble que le port Thunderbolt toujours fonctionnel causera 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 pourrait être affecté et une réinitialisation de la NVRAM avec une danse de réglage variable suivante décrite ci-dessus sera nécessaire, encore une fois. Dans de tels cas, il semble 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 en veille.
Dans les limites décrites au début de cette réponse: La plupart des utilisateurs signalent un succès complet.
Mods / hacks matériels
Plusieurs façons disponibles maintenant, certaines mauvaises, d'autres bonnes.
Mauvaise solution: une modification matérielle très bon marché est disponible sur / à partir de RealMacMods: bien
qu'ils utilisent un moyen relativement compliqué de définir la variable EFI nécessaire avec linux, ce qui suit a l'avantage de couper complètement la tension de base du dGPU en supprimant une seule petite résistance ! (Photos sur le lien)
Lors de ce redémarrage, il est essentiel de démarrer une fois en mode sans échec (maintenez la touche Maj enfoncée tout au long du démarrage), puis de choisir l'arrêt (et non le redémarrage) dans le menu.
Faites ce démarrage en toute sécurité avec la résistance R8911 en place. Sans ce BOTTE SAFE, les prochaines étapes peuvent ne pas fonctionner.
Ne démarrez plus 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, ce qui peut interférer avec le processus suivant.
Cela entraînera désormais l'arrêt automatique de votre MacBook Pro sur la Radeon, mais il consommera toujours de l'énergie, créera de la chaleur et sera visible par le système d'exploitation.
Nous avons découvert que la simple suppression d'une résistance résoudra 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 carte logique.
La résistance en question est R8911 sur le MBP 17 ″ et R8911 sur le MBP 15 ″ une résistance de 1 Ohm qui fournit un chemin de courant vers le convertisseur CC / CC ISL6263C.
Cette résistance contrôle l'alimentation du régulateur de tension qui fournit la tension de base au processeur graphique Radeon. Autrement dit, pas de tension de base, pas de GPU. Vous trouverez la résistance juste à droite d'un ventilateur de refroidissement (dans l'orientation ci-dessus). Il sera proche de la puce du convertisseur de tension ISL. C'est la puce que nous désactiverons.
Retirez-le. La méthode préférée est une station de refusion professionnelle, mais un fer à repasser et une main ferme vous mèneront là où vous devez être. Si vous avez utilisé du flux pour le retirer (pas nécessaire), assurez-vous de nettoyer avec un peu d'alcool ou un autre solvant approprié.
C'est essentiellement ça. La prochaine fois que vous démarrerez, vous remarquerez que votre problème de défaut de processeur graphique a disparu, et vous ne verrez plus le processeur graphique AMD en tant que matériel installé.
Je n'ai pas testé cela mais cela devrait éliminer tout besoin de prendre soin des kexts et également résoudre tous les problèmes concernant le sommeil, le réveil, l'hibernation, le redémarrage, etc.
Une mise en garde pour considérer cette méthode: car elle semble également reposer sur le fait d'avoir cet ensemble de variables NVRAM il semble qu'il soit absolument essentiel d'avoir une méthode entièrement automatisée en place pour définir cette variable sans aucune intervention de l'utilisateur. (Comme un bâton Linux qui apporte les modifications nécessaires) Sinon, une réinitialisation NVRAM pourrait pratiquement brique la machine. Le vendeur prétend n'avoir aucune donnée à ce sujet!
(Après avoir lu l'histoire d'un utilisateur mordu par cette méthode, se retrouvant avec juste un écran noir: il semble possible d'accéder à distance à la machine avec VNC ou ssh, donc si ceux-ci sont configurés à l'avance, il peut en effet être une option pas si mauvaise après tout, car la variable nvram peut être définie de cette manière. Rappelez-vous: histoire Internet non testée.)
Solution matérielle permanente, fiable et bon marché!
Dosdude1 a apparemment trouvé une solution qui semble être le Saint Graal pour ce problème: Désactiver définitivement le GPU dédié MacBook Pro 15 "/ 17" 2011 - gMux IC Bypass
- L'option A, qui sera détaillée ci-dessous, consiste à câbler les lignes de sortie LVDS des lignes graphiques de sortie LVDS graphiques directement aux lignes se connectant à l'écran.
- L'option B serait de reprogrammer le gMux IC (qui est simplement un micro-contrôleur Lattice LFXP2), avec un firmware personnalisé pour désactiver la fonctionnalité de commutation GPU. Je peux 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.
C'est presque facile. Tout ce dont vous avez besoin, c'est de différentes longueurs de fil . Pour avoir un aperçu:
également sur youtube!
La `` mauvaise solution '' d'en haut est maintenant transformée en une solution matérielle presque professionnelle et prédéfinie, éliminant la `` mauvaise '' précédente de cette approche:
Tiresias (le GPUkiller):
Le Tiresias 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).
Ce sont tous les modèles qui ont la carte mère 820-2914-A, 820-2914-B, 820-2915-A ou 820-2915-B.
Les cartes 820-2914 et 820-2915 ont deux GPU. Le GPU interne (Intel) qui fait partie du PCH et un GPU AMD externe (discret). C'est le GPU externe qui échoue dans «un petit pourcentage des systèmes MacBook Pro» (Apple en parle: «très nombreux»). Le Tiresias écrit la variable nvram 'gpu-power-prefs' dans la ROM afin que le Mac n'utilise plus le GPU AMD externe (discret) (mort). Si l'utilisateur efface la NVRAM (PRAM), il n'y a pas de problème car Tiresias réécrira l'enregistrement et le Mac fonctionnera à nouveau.
Cela en fait la solution idéale pour redonner vie à un 820-2914 ou 820-2915 avec un GPU 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. En dehors de cela, le R8911 doit être retiré pour couper l'alimentation du GPU mort. Cela économise de l'énergie, génère moins de chaleur et préserve la durée de vie de la batterie. La suppression de R8911 empêche également le Mac d'être dérouté par le GPU mort car même avec le GPU éteint, il essaiera toujours de parler au GPU mort. Selon les contacts internes du GPU qui sont rompus, cela peut perturber ou même 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.
Détails techniques du Tiresias (le GPUkiller) Le Tiresias 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).
Ce sont tous les modèles qui ont la carte mère 820-2914-A, 820-2914-B, 820-2915-A ou 820-2915-B.
Les cartes 820-2914 et 820-2915 ont deux GPU. Le GPU interne (Intel) qui fait partie du PCH et un GPU AMD externe (discret). C'est le GPU externe qui échoue dans «un petit pourcentage des systèmes MacBook Pro» (Apple en parle: «très nombreux»). Le Tiresias écrit la variable nvram 'gpu-power-prefs' dans la ROM afin que le Mac n'utilise plus le GPU AMD externe (discret) (mort). Si l'utilisateur efface la NVRAM (PRAM), il n'y a pas de problème car Tiresias réécrira l'enregistrement et le Mac fonctionnera à nouveau.
Cela en fait la solution idéale pour redonner vie à un 820-2914 ou 820-2915 avec un GPU 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. En dehors de cela, le R8911 doit être retiré pour couper l'alimentation du GPU mort. Cela économise de l'énergie, génère moins de chaleur et préserve la durée de vie de la batterie. La suppression de R8911 empêche également le Mac d'être dérouté par le GPU mort car même avec le GPU éteint, il essaiera toujours de parler au GPU mort. Selon les contacts internes du GPU qui sont rompus, cela peut perturber ou même planter le Mac.
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. Le sommeil 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)
À notre connaissance, 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 de High Sierra et semble en avoir fait un gâchis. Les commandes de rétroéclairage ne fonctionneront pas. Et pire encore, après le réveil de la machine, le rétroéclairage n'est pas du tout réactivé.
Pour résoudre le problème de non-retour du rétro-éclairage après la mise en veille, retirez le R9704 et connectez la broche 2 du R9704 à la broche 1. C9711. L'inconvénient est qu'avec cette modification, la luminosité sera également en pleine luminosité avec les anciens systèmes d'exploitation.
Tiresias pour 820-2915 (15 pouces) Quantité un (1) Livraison incluse (dans le monde entier) 60 EURO.
Mise à jour pour une solution logicielle unique
La procédure ci-dessus semble avoir été transposée dans une application liée au hack matériel! Eh bien, au moins en partie. Mais d'un autre côté, cette application est plus universelle que la soution ci-dessus, car elle semble gérer également les cartes NVidia, c'est-à-dire: c'est pour désactiver tous les processeurs discrets dans tous les Mac.
Hélas, cette application faite par dosdude1 et mal documentée. L'écran du fichier Lisez-moi indique qu'il définirait la variable NVRAM, déplacerait tous les pilotes d'accélération graphique, puis installerait un launchdaemon pour gérer les mises à jour et s'assurer que la variable reste définie.
Non testé par moi et non approuvé par moi si vous avez déjà suivi la procédure décrite ci-dessus!
Mais si la procédure n'a pas fonctionné à un moment donné pour vous ou semble tout simplement intimidante pour commencer, vous pouvez essayer ceci:
dosdude1: D'autres logiciels non documentés que j'ai écrits sont stockés ici: MacBook Pro dGPU Disabler.zip
Vous devrez peut-être réexaminer la procédure ci-dessus, car l'application semble manquer d'améliorer la partie de la gestion thermique (si vous modifiez le matériel en supprimant le transistor, cela devient une ambiance: mélanger et assortir).
Si quelqu'un teste cela, veuillez donner votre avis ici via des commentaires ou une modification.
Mise à jour de Pâques 2019: solution à 20 $ qui utilise un ordinateur Windows 64 bits et un programmeur FPGA LSP HW-USBN-2A ICSP pour appliquer un micrologiciel personnalisé au circuit intégré gMux. Dosdude1 prétend que c'est une solution `` parfaite '', ce qui signifie que même sous HighSierra et Mojave, la durée de vie de la batterie, la température, le contrôle de la luminosité et le réveil / sommeil 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 programmeur); et soudant actuellement quelques fils sur la carte mère.)