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 ?
Réponses:
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:
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:
avec le contenu suivant:
puis rendez-le * 1 exécutable et actif:
* 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
):Et si la méthode de chargement ci-dessus a réussi, cela devrait apparaître ajouté à la liste:
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:
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:
- Entrez le contenu suivant dans ce fichier:
- Rendez maintenant cet exécutable:
À 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:
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.
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)
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
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:
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.)
la source
agc
tomber 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à…reboot
après la SIP initiale désactivercsrutil disable
et 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.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.
csrutil disable
et appuyez sur Retour.mv
commander.Si cela fonctionnait, réactivez SIP:
la source
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.
langlangc
en appuyant longuement sur Cmd + S (Cmd + R ne se charge pas en donnant l'écran blanc. commentaire)sh /force-iGPU-boot.sh
csrutil disable nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 nvram boot-args="-v"
/System/Library/Extensions-off
dossier existant est supprimé après avoir effectué une sauvegarde/sbin/mount -uw / mkdir -p /System/Library/Extensions-off mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/ touch /System/Library/Extensions/
nvram boot-args="agc=0"
reboot
pour 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.kext
en place !!!Mise à jour 11 novembre 2019
Il
AMD6000Controller.kext
est nécessaire de remettre le contrôle de la luminosité au travail comme d'habitude. Ce kext doit être présent à/System/Library/Extensions/
.la source
/force-iGPU-boot.sh
script non? et monExtensions-off
répertoire était déjà en place, je viens de déplacer le nouveauAMDRadeonX3000.kext
et 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.