Problème de GPU - Le démarrage se bloque sur un écran gris


43

J'ai trouvé cela en fonction de mon problème dans ce fil: le
démarrage se bloque sur un écran gris (même lors du démarrage à partir d'un lecteur USB avec une nouvelle installation d'OS X)

Mon MacBook Pro 15 "début 2011 avec AMD Radeon HD 6750M a présenté une corruption de l'affichage et des pannes / réinitialisations du système associées sur une période de deux semaines avant qu'il n'ait complètement échoué. Le démarrage progressait à travers l'écran gris avec le logo Apple et le spinner, mais juste au moment où il semble qu'il aurait dû passer à l'écran de connexion, le logo Apple et le spinner disparaîtraient et resteraient sur un écran gris vierge.

Au début, je soupçonnais la corruption du disque dur et j'ai essayé d'y remédier. En vain, j'ai essayé ce qui suit, chacun continuant de se bloquer comme décrit ci-dessus:

Démarrage sécurisé
Démarrage dans la récupération (y compris Internet Recovery)
Démarrage à partir du support d'installation sur le lecteur USB
Démarrage à partir de l'installation d'OS X sur le lecteur USB
Effacer NVRAM
Réinitialiser SMC

J'ai également exécuté le test matériel Apple à plusieurs reprises sans qu'il ne détecte aucun problème.

Le démarrage sécurisé (Cmd + Shift + V) affiche tout ce que je m'attendais à voir mais se bloquerait comme décrit ci-dessus.

Après avoir rencontré plus de messages en ligne sur les forums de discussion d'Apple sur les problèmes liés au GPU, j'ai revisité cela comme la cause:

MacBook Pro 2011 et carte graphique discrète ou MacBook Pro 2011 et carte graphique discrète

En essayant de démarrer Ubuntu à partir d'un lecteur flash USB, je n'ai pu aller jusqu'à GRUB. Lorsque vous essayez de démarrer Ubuntu Desktop ou d'exécuter le graphicstest dans GRUB, le système se bloque.

À ce stade, l'exécution d'Apple Hardware Test s'est interrompue juste avant la fin du test standard, peut-être [deviner] lors d'un test vidéo.

Sur la base des conseils des messages Apple Discussions ci-dessus, j'ai fait ce qui suit:

Démarrage en mode mono-utilisateur
Exécutez les commandes suivantes:

/sbin/fsck -fy /
/sbin/mount -uw /
mkdir /Disabled_System_Library_Extensions
cd /Disabled_System_Library_Extensions
mv /System/Library/Extensions/ATI* .
mv /System/Library/Extensions/AMD* .
touch /System/Library/Extensions
exit

Cette fois, la machine a démarré complètement. Cependant, les graphiques sont extrêmement lents, même juste des transitions lors de la réduction des fenêtres. J'emmènerai mon MBP à Apple pour demander un remplacement car le grand nombre de rapports d'autres personnes confrontées à des problèmes similaires fait ressembler à une récurrence d'une défaillance similaire liée au GPU qui les a amenés à effectuer un rappel.

Mais lorsque j'utilise la commande "mv", les fichiers ne sont pas déplacés (ni supprimés) et cela me montre:
Sandbox deny (01) file-write-unlinked…

Toute solution ?



@klanomath Yep, c'est le problème. Arrivé à mon ancien MBP aussi (juste un écran verdâtre plutôt que gris).
owlswipe

Réponses:


81

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.kextvraiment é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

  1. 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;

  2. Maintenant, rallumez et maintenez

    Cmd+ Opt+ p+ r
    en même temps jusqu'à ce que vous entendiez deux fois le carillon de démarrage.

  3. Démarrez dans Single User Recovery en maintenant

    Cmd+ r+s

  4. Désactiver SIP: entrez:

    csrutil disable

  5. 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

  6. activer le mode de démarrage détaillé:

    nvram boot-args="-v"

  7. redémarrer en mode mono-utilisateur en maintenant

    Cmd+ s
    au démarrage

  8. monter la partition racine accessible en écriture

    /sbin/mount -uw /

  9. créer un répertoire de sauvegarde kext

    mkdir -p /System/Library/Extensions-off

  10. éloignez seulement UN kext offensant:

    mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/

  11. informer le système de mettre à jour son kextcache:

    touch /System/Library/Extensions/

  12. 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:

  1. 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 ).

  2. 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é.

  3. 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: entrez la description de l'image ici é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.

entrez la description de l'image ici entrez la description de l'image ici entrez la description de l'image ici


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.)


2
@Tarek Strange. Vous semblez être sur High Sierra. Je ne sais pas s'ils ont resserré cela plus récemment. Avez-vous un ancien système amorçable? De Yosemite ça marche toujours; dans Sierra comme décrit ci-dessus (et dans les deux cas, le paramètre restera). Sinon, je suggère de désactiver SIP et de réessayer (puis peut-être aussi à partir d'un démarrage normal?). (Laisser agctomber n'est pas catastrophique, j'ai couru le Mac pendant un mois sans trouver cette astuce. L'amélioration ne varie que de 'un peu' à 'OK, presque génial'). là…
LаngLаngС

6
Après quelques mois à essayer de récupérer mon mpb de 17 "fin 2011 dans le pays des vivants, j'ai finalement découvert que le problème discret du GPU était le coupable. Honnêtement @LangLangC pendant toutes mes années dans l'informatique, je n'ai jamais vu une telle une explication logiquement écrite et complète d'une solution bien conçue, avec des détails de niveau indéniablement expert. Et tout cela d'un désir altruiste d'aider les autres. Je tape ceci sur mon MBP relancé, et même si je sais que vous ne l'avez pas fait faites-le pour gagner de l'argent, vous m'avez économisé potentiellement des milliers, donc je vais vous
envoyer un

2
Pour mémoire, au 10.13.4 les kexts liés aux GPU AMD sont: com.apple.kext.AMDLegacySupport (1.6.6), com.apple.kext.AMD6000Controller (1.6.6), com.apple.kext.AMDLegacyFramebuffer (1.6.6) et com.apple.kext.AMDRadeonX3000 (1.6.6).
Kendall Lister du

4
A travaillé pour moi sur un 17" début 2011 en cours d' exécution Sierra! Affichage externe ne fonctionne pas , mais mieux qu'un paperweight géant! Prenez note (pour les noobs comme moi), vous devez saisir rebootaprès la SIP initiale désactiver csrutil disableet après les changements de NVRAM gpu en cours de récupération. Je ne savais pas comment redémarrer à partir du terminal de récupération, et j'ai essayé de mettre hors tension, mais le changement SIP n'a pas persisté de cette façon.
Will Buck

2
Merci pour cette merveilleuse compilation de toutes les solutions possibles pour notre bien-aimé 2011 mbp. J'ai ressuscité mon carnet mort avec la méthode de suppression de nvram et kext sur High Sierra maintenant mise à jour vers 10.13.6. Tout fonctionne comme il se doit, l'ordinateur portable fonctionne plus frais, le contrôle de la luminosité fonctionne bien, le sommeil fonctionne également correctement. Aujourd'hui, j'ai connecté le câble Thunderbolt à un autre Mac fonctionnel en mode disque cible, mais rien. Redémarrage de 2011 mbp en TDM, rien sur d'autres mac. Je sens que la connexion de données Thunderbolt se fait via le GPU, donc c'est cassé. Contrairement à certaines mentions de «la tuberculose devrait fonctionner». Je vais le tester avec eGPU maintenant
Mayank Chandak

1

Si le problème est que vous ne pouvez pas déplacer ces fichiers, c'est probablement la protection de l'intégrité du système qui vous arrête. Je suppose que vous êtes sur El Capitan ou Sierra.

  • Arrêtez votre ordinateur portable.
  • Appuyez sur Command + R puis sur le bouton d'alimentation pour démarrer en mode de récupération.
  • Cliquez sur le menu Utilitaires et sélectionnez Terminal.
  • Tapez csrutil disableet appuyez sur Retour.
  • Fermez l'application Terminal et redémarrez en mode de récupération.
  • Essayez maintenant de redémarrer en mode mono-utilisateur et essayez de mvcommander.

Si cela fonctionnait, réactivez SIP:

  • Arrêtez votre ordinateur portable.
  • Appuyez sur Command + R puis sur le bouton d'alimentation pour démarrer en mode de récupération.
  • Cliquez sur le menu Utilitaires et sélectionnez Terminal.
  • Tapez csrutil enable et appuyez sur retour.
  • Fermez l'application Terminal et redémarrez en mode de récupération.

@klanomath merci pour votre réponse rapide. Mais le seul mode que je peux utiliser est le mode mono-utilisateur. Il se fige en mode de récupération même en mode de récupération Internet.
Ghazi Marzouk

@GhaziMarzouk Snacking_IT a répondu à votre question! Je viens de le
modifier

@Snacking_IT merci pour votre réponse rapide. Mais le seul mode que je peux utiliser est le mode mono-utilisateur. Il se fige en mode de récupération même en mode de récupération Internet
Ghazi Marzouk

2
Tout comme une mise à jour, dans la réponse de @ LangLangC, je n'ai pas pu désactiver SIP sur El Capitan lors des étapes 1.3 et 1.4, car la récupération par utilisateur unique monte uniquement le lecteur en lecture seule. L'approche ci-dessus (démarrage en mode de récupération à la place) fonctionne, il est donc utile d'inclure ces informations.
Twitch_City

1

Merci à cette réponse https://apple.stackexchange.com/a/295805/300460 de https://apple.stackexchange.com/users/251859/langlangc . Je l'ai suivi quand j'ai eu ce problème en septembre dernier 2018. Cependant, j'ai eu un peu de mal à comprendre les étapes delta exactes à effectuer pour la deuxième fois, lorsque j'ai rencontré le même problème hier à nouveau lorsque j'ai fait la mise à jour de sécurité OSX 2019-003. Donc, j'ai pensé à mettre exactement ces étapes en pensant aux utilisateurs qui pourraient rencontrer ce problème pour la deuxième fois. Encore une fois, merci à langlangc pour l'original.

J'étais sur OSX 10.13.6 au moment où j'ai fait la mise à jour.

  1. Redémarrez en mode mono-utilisateur langlangcen appuyant longuement sur Cmd + S (Cmd + R ne se charge pas en donnant l'écran blanc. commentaire)
    • Courir sh /force-iGPU-boot.sh
  2. Redémarrez en mode de récupération en maintenant la touche Cmd + r enfoncée
    • Exécutez ces commandes. En fait, je les mets dans un petit fichier de script /force-iGPU-boot_without_sudo.sh.
      csrutil disable nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 nvram boot-args="-v"
  3. Redémarrez en mode mono-utilisateur en appuyant longuement sur Cmd + s
    • Assurez-vous qu'un /System/Library/Extensions-offdossier existant est supprimé après avoir effectué une sauvegarde
    • Exécutez ces commandes. Encore une fois, je les mets dans un petit fichier de script /move_out_amd_kext.sh /sbin/mount -uw / mkdir -p /System/Library/Extensions-off mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/ touch /System/Library/Extensions/
    • Entrer nvram boot-args="agc=0"
    • Entrez rebootpour le démarrer normalement.

Tout le reste devrait fonctionner comme prévu, comme vous auriez fait toutes les autres étapes nécessaires lorsque vous l'avez fait fonctionner pour la première fois. Bonne chance.

Mise à jour 12 août 2019

J'avais l'habitude de dépendre de la solution logicielle proposée par @LangLangC. Cependant, la récente mise à jour d'août a révélé que le démarrage normal était suspendu à la barre de progression. Je peux passer en mode de démarrage sécurisé, mais je trouve que l'écran scintille beaucoup.

Mise à jour 14 août 2019

Démarré avec succès lorsque j'ai désactivé le SIP en mode de récupération. Je ne me souviens pas si je l'ai fait dans le passé - mais maintenant je suppose que je l'ai peut-être fait.

J'ai perdu beaucoup de temps à soupçonner de nombreuses raisons différentes - y compris l'aggravation du problème de processeur graphique ou des bogues potentiels avec la mise à jour de sécurité 10.13.6 2019-004.

Cependant, maintenant j'ai remarqué qu'il a démarré cette fois même avec la problématique /System/Library/Extensions/AMDRadeonX3000.kexten place !!!

Mise à jour 11 novembre 2019

Il AMD6000Controller.kextest nécessaire de remettre le contrôle de la luminosité au travail comme d'habitude. Ce kext doit être présent à /System/Library/Extensions/.


Pourriez-vous expliquer ce que vous voulez dire exactement par "2e fois"? Ce qui précède semble avoir réinitialisé NVRAM / PRAM au cours du processus. Ou est-ce bien ce que vous avez fait avec un hack fonctionnel sur 10.13 et juste appliqué la récente SecUpdate? (Le SecUpdate lui-même ne devrait rien faire pour invalider le hack lui-même, mais installer un AMD.kext fonctionnel dans le mauvais emplacement du hack, et doit donc être déplacé). Ou de l'autre côté: votre NVRAM a-t-elle été réinitialisée lors de la mise à jour?
LаngLаngС

J'étais déjà sur un hack de travail sur 10.13.6 qui a été fait en septembre 2018 dernier suite à votre réponse. J'ai ensuite appliqué la mise à jour de sécurité hier, après quoi je suis à nouveau bloqué avec un écran blanc. Je ne joue jamais avec les fichiers KEXT, sauf si je dois suivre vos instructions pour résoudre le problème d'écran blanc après la mise à jour de sécurité. Avec juste l'étape 1 (1er mode mono-utilisateur) n'a pas résolu le problème, j'ai donc dû passer à l'étape-2 (mode de récupération) par la suite à l'étape-3 (mode mono-utilisateur à nouveau).
Raj

Je viens de mettre à jour mon volume High Sierra avec la dernière mise à jour de sécurité 2019-005. La barre de processus est restée bloquée au redémarrage, j'ai donc attendu que les fans s'arrêtent et j'ai redémarré mon MBP manuellement en mode mono-utilisateur et j'ai suivi votre guide. A bien fonctionné! Quelques questions cependant: pourquoi devez-vous répéter le hack NVRAM à l'étape 2? c'est déjà dans le /force-iGPU-boot.shscript non? et mon Extensions-offrépertoire était déjà en place, je viens de déplacer le nouveau AMDRadeonX3000.kextet je l'ai appelé AMDRadeonX3000v2.kext. Il semble préférable de conserver et de charger l'original comme indiqué dans le guide @LangLangC, je suppose.
salle

1
@aroom Ce qui précède répète quelques étapes redondantes, sans faire de mal, juste une approche ceinture et bretelles. La clé de la mise à jour est NVRAM en place un travail démarrage X3000 pend. Très souvent, Apple a expédié un kext défectueux qui dépendait d'une installation d'origine, tous les deltas manquant un fichier crucial. (Pour des résultats optimaux, nous avons dû mv l'ancien kext en place, puis mettre à jour, puis mv vers Ext-off à nouveau) Maintenant qu'Apple a finalement corrigé cela, il est préférable d'utiliser le plus récent kext de la mise à jour, en faisant correspondre les numéros de version dans la mise à jour . Avec SIP désactivé, il suffit de démarrer SafeMode et mv sur Ext-off, en supprimant la version précédente.
LаngLаngС
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.