il faut que @macomaniac agisse avec le terminal .... comme le post sur la suppression du fichier list
iMac Benchmark "single core" divisé par 10 sur iMac late 2013
- Créateur du sujet ness_Du_frat
- Date de début
Maco, t'es mon seul espoir ^^ Mais ninkasi67, tu m'as recadrée sur la bonne piste avec ton histoire de température. Je crois que c'est vraiment ça, en fait. Et je doute que mon CPU soit à 255° comme a l'air de le prétendre le terminal (même si je pense que ce sont des degrés Fahrenheit).
@macomaniac voila le sujet pour supprimer une protection ! j'ai mon macbook pro qui est present mais pas son iMac ....
Voici une solution de contournement, qui fonctionne (on l'a testé) mais à utiliser à vos risques et périls. En effet, il s'agit tout simplement de désactiver cette « protection » du noyau. Par ailleurs, il est possible que la manipulation saute à la prochaine mise à jour.
Voici donc la série de commandes à effectuer dans le terminal :
Récupérez déjà le modèle de votre Mac via la commande suivante :
system_profiler -detailLevel mini | grep "Model Identifier:"
Normalement, vous verrez une ligne du type « MacBookPro6,1 » s'afficher.
Nous allons maintenant retirer un fichier « .plist » chargé de gérer ce « refroidissement logiciel » pour votre Mac. Pour cela, il faut vous rendre dans ce répertoire :
cd /System/Library/Extensions/IOPlatformPluginFamily.kext/
Puis, placez-vous dans ce sous-dossier et listez le contenu :
cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/
ls
A ce stade, vous aurez sous vos yeux une série de fichiers, dont l'un correspondant à l'identifiant de votre machine (voir plus haut). Il suffit alors de déplacer ce fichier (sur le bureau, par exemple) pour rendre la fonction inopérante.
Par exemple :
mv MacBookPro6_1.plist /Users/didier/Desktop
Il suffit enfin de redémarrer et vous ne devriez plus voir le fameux « kernel_task » monopliser tout votre CPU sans votre accord.
Comme vu plus haut, il ne s'agit pas à proprement parler d'une solution, mais plutôt de soigner les symptômes d'un problème, voire d'un bug de Mac OS X (à confirmer) : il est possible que votre Mac surchauffe trop facilement, ou qu'un processus/extension soit à l'origine de cette montée anormale en température.
Voici une solution de contournement, qui fonctionne (on l'a testé) mais à utiliser à vos risques et périls. En effet, il s'agit tout simplement de désactiver cette « protection » du noyau. Par ailleurs, il est possible que la manipulation saute à la prochaine mise à jour.
Voici donc la série de commandes à effectuer dans le terminal :
Récupérez déjà le modèle de votre Mac via la commande suivante :
system_profiler -detailLevel mini | grep "Model Identifier:"
Normalement, vous verrez une ligne du type « MacBookPro6,1 » s'afficher.
Nous allons maintenant retirer un fichier « .plist » chargé de gérer ce « refroidissement logiciel » pour votre Mac. Pour cela, il faut vous rendre dans ce répertoire :
cd /System/Library/Extensions/IOPlatformPluginFamily.kext/
Puis, placez-vous dans ce sous-dossier et listez le contenu :
cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/
ls
A ce stade, vous aurez sous vos yeux une série de fichiers, dont l'un correspondant à l'identifiant de votre machine (voir plus haut). Il suffit alors de déplacer ce fichier (sur le bureau, par exemple) pour rendre la fonction inopérante.
Par exemple :
mv MacBookPro6_1.plist /Users/didier/Desktop
Il suffit enfin de redémarrer et vous ne devriez plus voir le fameux « kernel_task » monopliser tout votre CPU sans votre accord.
Comme vu plus haut, il ne s'agit pas à proprement parler d'une solution, mais plutôt de soigner les symptômes d'un problème, voire d'un bug de Mac OS X (à confirmer) : il est possible que votre Mac surchauffe trop facilement, ou qu'un processus/extension soit à l'origine de cette montée anormale en température.
La liste s'arrête à iMac12,2, j'ai un iMac14,1... Ce qui me fait une belle jambe.
Et mon proc est à 28°, si jamais ^^ C'est juste le truc qui est con. En même temps, vu qu'il ne fout rien d'autre que kernel_task, il ne peut pas beaucoup monter...
Et mon proc est à 28°, si jamais ^^ C'est juste le truc qui est con. En même temps, vu qu'il ne fout rien d'autre que kernel_task, il ne peut pas beaucoup monter...
M
Membre supprimé 1060554
Invité
Tu as 2418.23 ms/s de kernel_task ? Fichtre ! Si tu ouvres le «Moniteur d'activité» > Processeur > % processeur --> la kernel_task est à combien de % ?
Vous avez beau m'appeler à l'aide > en la matière c'est comme compter sur une enclume quand on est en train de boire la tasse
Parce que le kernel > c'est une espèce de répartiteur intervenant entre le software et le hardware. Comment savoir la raison exacte qui fait surconsommer du CPU par l'intermède du kernel ? Difficile d'alléguer une provenance logicielle tierce a priori, puisqu'on a une clean install de «Yosemite» (avec une pincée de logiciels de test en sus). S'il s'agit d'un problème matériel > je suis incompétent.
Une mince piste expérimentale : l'architecture du noyau a changé entre «Mavericks» (et les OS antérieurs) et «Yosemite» (et les OS postérieurs) --> passage d'un type mach_kernel à un type kernel. Donc essayer avec «Mavericks» qui doit être l'OS-d'usine de l'iMac Late_2013 et dont le noyau est un mach_kernel. Pour installer «Mavericks» > démarrage en mode Internet Recovery (⌘⌥R --> 10' de globe en rotation avant d'ouvrir la session Recovery) > "Ré-installer OS X" : ça doit bien être «Mavericks» qui est proposé à la restauration, non ?
Cela dit : ça ne mène pas loin, à part introduire une variation logicielle. Si le kernel répercute un problème matériel x sur le processeur > ça ne va pas changer la donne.
Autre piste : ouvrir la «Console» > scruter les lignes kilométriques qui s'affichent > est-ce qu'intervient une récurrence massive signalant l'échec d'une opération ?
Vous avez beau m'appeler à l'aide > en la matière c'est comme compter sur une enclume quand on est en train de boire la tasse
Une mince piste expérimentale : l'architecture du noyau a changé entre «Mavericks» (et les OS antérieurs) et «Yosemite» (et les OS postérieurs) --> passage d'un type mach_kernel à un type kernel. Donc essayer avec «Mavericks» qui doit être l'OS-d'usine de l'iMac Late_2013 et dont le noyau est un mach_kernel. Pour installer «Mavericks» > démarrage en mode Internet Recovery (⌘⌥R --> 10' de globe en rotation avant d'ouvrir la session Recovery) > "Ré-installer OS X" : ça doit bien être «Mavericks» qui est proposé à la restauration, non ?
Cela dit : ça ne mène pas loin, à part introduire une variation logicielle. Si le kernel répercute un problème matériel x sur le processeur > ça ne va pas changer la donne.
Autre piste : ouvrir la «Console» > scruter les lignes kilométriques qui s'affichent > est-ce qu'intervient une récurrence massive signalant l'échec d'une opération ?
Ben là j'ai éteint le machin, j'en avais marre et j'avais faim. Mais le kernel task était toujours autour des 200% voire plus.
Yosemite, j'ai pas laissé longtemps, c'était encore plus lent.
Mavericks, il a arrêté de me le proposer, maintenant, c'est uniquement El Capitan. J'ai un dmg, mais pas possible de faire une clé de boot car disk x maker ne fonctionne pas avec Mavericks. Mais je doute que ça change grand chose, car c'était déjà la même merde avec Yosemite.
J'ai beau fouiller internet, je trouve des gars dans la même situation que moi, mais pas une seule solution. Tous les autres qui ont le problème du kernel task, c'est une histoire de temperature, ou alors ils ont pu résoudre avec la manip au-dessus. (Ce que j'ai fait à l'époque pour mon MacBook Pro parce que c'était ingérable). Mais comme mon mac n'est pas dans la liste, impossible de faire cette manip.
Comme le smc est défectueux (erreur pfm006), je pense qu'il prend la valeur la plus élevée possible pour des raisons de sécurité. Et en effet, si c'était un portable ou un iMac dans la liste, hop, on vire le fichier qui pose problème, on gère la temperature avec le contrôleur de ventilateurs (ce que je fais maintenant depuis des années sans souci avec le MacBook Pro) et kernel task nous fout une paix royale.
Là, je ne sais même pas si la pâte thermique changerait quelque chose.
Édit : je crois savoir pourquoi il me propose El Capitan : j'ai une partition de restauration sur mes disques. Du coup il me chope ça par défaut. J'avais toujours fait Cmd R, qui allait choper le internet recovery car il n'y avait rien d'autre. Je vais tester Cmd alt R et je reviens.
Installation en cours, ça rame déjà sur l'écran d'Internet recovery, je pourrai donc revenir dans minimum 2h (à moins que ca ne mette 6h comme la dernière fois) pour dire que ca n'a rien changé, mais au moins, on aura avancé un peu.
Yosemite, j'ai pas laissé longtemps, c'était encore plus lent.
Mavericks, il a arrêté de me le proposer, maintenant, c'est uniquement El Capitan. J'ai un dmg, mais pas possible de faire une clé de boot car disk x maker ne fonctionne pas avec Mavericks. Mais je doute que ça change grand chose, car c'était déjà la même merde avec Yosemite.
J'ai beau fouiller internet, je trouve des gars dans la même situation que moi, mais pas une seule solution. Tous les autres qui ont le problème du kernel task, c'est une histoire de temperature, ou alors ils ont pu résoudre avec la manip au-dessus. (Ce que j'ai fait à l'époque pour mon MacBook Pro parce que c'était ingérable). Mais comme mon mac n'est pas dans la liste, impossible de faire cette manip.
Comme le smc est défectueux (erreur pfm006), je pense qu'il prend la valeur la plus élevée possible pour des raisons de sécurité. Et en effet, si c'était un portable ou un iMac dans la liste, hop, on vire le fichier qui pose problème, on gère la temperature avec le contrôleur de ventilateurs (ce que je fais maintenant depuis des années sans souci avec le MacBook Pro) et kernel task nous fout une paix royale.
Là, je ne sais même pas si la pâte thermique changerait quelque chose.
Édit : je crois savoir pourquoi il me propose El Capitan : j'ai une partition de restauration sur mes disques. Du coup il me chope ça par défaut. J'avais toujours fait Cmd R, qui allait choper le internet recovery car il n'y avait rien d'autre. Je vais tester Cmd alt R et je reviens.
Installation en cours, ça rame déjà sur l'écran d'Internet recovery, je pourrai donc revenir dans minimum 2h (à moins que ca ne mette 6h comme la dernière fois) pour dire que ca n'a rien changé, mais au moins, on aura avancé un peu.
Dernière édition:
En attendant l'installation, j'ai continué un peu à fouiller, je suis tombée sur plusieurs autres personnes avec l'erreur pfm006 (qui vendaient leurs ordis, donc impossible d'en savoir plus) et dont les ordis était hyper lents avec le systeme qui prenait 80% du proc en permanence (comme chez moi, donc). L'un d'entre eux a ouvert l'ordinateur pour changer la pâte thermique, sans succès. Mêmes symptômes que moi, à l'exception de l'écran (du coup, l'écran, c'est juste un truc en plus, ça ne vient pas de là), ventilo à fond, kernel task qui bouffe tout.
Aucune réponse nulle part, mais toujours l'erreur du contrôleur smc. Et à part faire un reset smc (déjà fait), je ne vois pas. Seule solution : by-pass le kernel task en lui faisant croire que le processeur a une temperature normale (ce qui est le cas), mais ca, aucune idée comment faire.
Apparemment, un des gars qui avait un souci de throttling a tenté une install de Windows, même problème, ca laggait pareil (à cause de bootcamp ?). Après, difficile de savoir qui a un réel problème de température et qui a comme moi un problème de contrôleur fou.
Aucune réponse nulle part, mais toujours l'erreur du contrôleur smc. Et à part faire un reset smc (déjà fait), je ne vois pas. Seule solution : by-pass le kernel task en lui faisant croire que le processeur a une temperature normale (ce qui est le cas), mais ca, aucune idée comment faire.
Apparemment, un des gars qui avait un souci de throttling a tenté une install de Windows, même problème, ca laggait pareil (à cause de bootcamp ?). Après, difficile de savoir qui a un réel problème de température et qui a comme moi un problème de contrôleur fou.
Ahah, parce que tu penses que ca a fini de l'installer ? La bonne blague... La dernière fois, ca a mis 6h...
Il reste 6 minutes, donc environ 1h (ca fait la même chose que l'autre fois (ce n'était pas le cas avec El Capitan), ca met 6 minutes, ca descend à 5, ca repart à 8, ca descend à 4, ca redescend à 6, etc. Sur la dernière ligne droite). Là je sors manger, je vous en dirai plus tout à l'heure.
J'ai un log de console pour qui veut...
https://ufile.io/6b616
Les firmwares SMC et EFI sont aux versions les plus récentes, je ne peux pas upgrader quoi que ce soit à ce niveau (j'ai essayé via mavericks, mais non, pas moyen, et en effet, après vérification sur le site, ils sont à jour).
Le problème est bel et bien matériel, car il apparaît déjà à l'install de l'OS. Donc c'est bien le SMC dans la puce qui est foireux. Mais si je me débarrassais du kernel_task qui est persuadé que mon proc est en train de brûler, je pense que l'ordi serait utilisable.
A mon avis, la pâte thermique ne changerait rien, quelqu'un l'a ait sans succès sur l'erreur PFM006.
https://ufile.io/6b616
Les firmwares SMC et EFI sont aux versions les plus récentes, je ne peux pas upgrader quoi que ce soit à ce niveau (j'ai essayé via mavericks, mais non, pas moyen, et en effet, après vérification sur le site, ils sont à jour).
Le problème est bel et bien matériel, car il apparaît déjà à l'install de l'OS. Donc c'est bien le SMC dans la puce qui est foireux. Mais si je me débarrassais du kernel_task qui est persuadé que mon proc est en train de brûler, je pense que l'ordi serait utilisable.
A mon avis, la pâte thermique ne changerait rien, quelqu'un l'a ait sans succès sur l'erreur PFM006.
Euh, je doute que ça change grand-chose si c'est un problème hardware qui intervient avant même l'installation d'un OS, et en plus si c'est pour avoir sur un ordi un OS que je ne veux pas, je préfère le vendre pour les pièces ^^
J'ai fait un diagnostic complet du système (sysdiagnose) : https://ufile.io/88726
Et apparemment, il y aurait un script qui permettrait de savoir ce que fait kernel_task, mais je n'ai pas du tout compris comment l'utiliser ni quoi en faire, c'était marqué de faire chmod a+x et de le faire tourner ensuite, mais sans autre explication, genre tout le monde sait forcément quoi faire avec : http://www.brendangregg.com/DTrace/hotkernel
J'ai fait un diagnostic complet du système (sysdiagnose) : https://ufile.io/88726
Et apparemment, il y aurait un script qui permettrait de savoir ce que fait kernel_task, mais je n'ai pas du tout compris comment l'utiliser ni quoi en faire, c'était marqué de faire chmod a+x et de le faire tourner ensuite, mais sans autre explication, genre tout le monde sait forcément quoi faire avec : http://www.brendangregg.com/DTrace/hotkernel
D
Deleted member 1099514
Invité
M
Membre supprimé 1060554
Invité
nessComme la kernel_task dévore du % de CPU quel que soit l'OS installé (même en clean install) > il me semble que le kernel répercute sur le processeur une tentative de prise en charge d'un composant matériel de la bécane qui n'arrive pas à se finaliser. À cause de ce composant matériel même.
Dans cette veine d'idées > on pourrait penser à une extension du noyau (kext). Au démarrage du Mac > l'EFI exécute le boot_loader : boot.efi (lanceur ou chargeur logiciel) > lequel active le kernel et procède à l'injection des kexts (extensions) dans le noyau. Car c'est un micro-noyau : il reçoit après lancement toute une collection d'extensions (sans les inclure a priori en mode interne).
Une extension (kext) est un pilote d'un composant hardware déterminé (BUS USB ou tout ce qu'on voudra) : le kernel prend donc en charge le pilotage des différentes fonctionalités physiques de la bécane. Il arrive fréquemment qu'il y ait des ratatouillages à ce niveau.
Mais ici on peut exclure résolument des kexts de tierce partie, puisque tu as des OS en clean install avec une collection d'extensions Apple©. Et des OS finalisés (version terminale, chaque fois). On peut donc en déduire (dans l'hypothèse où le coinçage provient d'une - ou de plusieurs - extensions) que le kernel n'arrive pas à engager le pilotage d'une fonctionalité physique de la bécane, parce qu'il y a une déficience matérielle : en gros l'« organe » ne répond pas au pilote.
Tu pourrais bien sûr faire un démarrage dit « sans extensions » (touche ⇧ = maj ou shift pressée au départ) > mais il ne faut pas se leurrer : un démarrage "sans extensions" ne signifie pas que toutes les kexts se trouvent échappées d'injection dans le kernel au démarrage > ce serait impossible, car le hardware serait "déconnecté" du logiciel. Ce type de démarrage, lorsqu'il y a des extensions de tierce partie, les écarte d'entrée - dans ton cas = clean install > il n'y en a aucune. Néanmoins, en cas de démarrage « sans extensions », une pincée de kext Apple dispensables se trouvent quand même échappées > donc tu peux quand même faire ce test occasu (solis)...
Je t'avais préconisé d'ouvrir l'application «Console» pour scruter les lignes de logs (un travail de... bénédictine) : s'il y a vraiment une kext qui n'arrive pas à prendre la main sur la fonctionnalité physique correspondante et si le kernel répète indéfiniment la tentative > ce qui consommerait du CPU > alors il devrait y avoir réitération de messages d'échec redondants dans les logs de la «Console».
Tu pourrais opérer aussi un démarrage en mode Verbose > pour scruter ensuite dans le procès-verbal s'il n'y a pas quelque chose qui saute aux yeux.
La conjecture que je t'ai exposée demeure d'ordre « général » - sans pointer quelque chose en particulier. Elle est peut-être non pertinente. Pour la raison suivante : quand survient un blocage décisif à l'injection de kexts > soit le kernel n'arrive jamais à dépasser cette étape pour passer au lancement de l'OS (ratatouillage indéfini, avec roue crantée giratoire qui tourne sans fin) ; soit il plante et c'est l'affichage d'un panneau de kernel_panic (si tu en avais un > au moins on saurait sur quoi le kernel plante).
Mais chez toi > le kernel ne plante pas du tout > il passe bien l'étape de l'injection des kexts > et il déclenche bien ensuite le processus launchd (le daemon INIT qui déploie le Système de l'OS). Peut-on imaginer qu'une injection de kext foirée continue ad vitam eternam d'être tentée après chargement de l'OS ? - hum... (ça, c'est en guise d'auto-critique de ma conjecture concernant les extensions).
[Rien ne dit, en effet, qu'il n'y a pas un problème intrinsèque du processeur et que la tâche du noyau ne se heurte pas à un problème à ce niveau...]
--------------------
Pour ce qui est de ton script > il faut savoir que si tu l'enregistres sous forme de fichier «TextEdit» de type .txt > il faut ensuite que tu modifies l'extension .txt en .sh (script shell) > puis que tu passes dans le «Terminal» une commande du type :
Bloc de code:
chmod u+w /[chemin_au_fichier]/[nom_du_fichier]Une fois fait > dans la fenêtre du «Terminal» tu peux faire un :
Bloc de code:
sudo /[chemin_au_fichier]/[nom_du_fichier]Hello !
Alors le démarrage sans extension, si c'est comme le safe boot, déjà testé sans succès. Le log console est à la page précédente.
Jai démarré avant hier en mode verbose et j'ai pu voir des warnings mais ça allait trop vite et je me suis dit qu'il faudrait que je cherche comment choper le log du démarrage d'une façon ou d'une autre mais je n'ai pas re-regardé.
jai aussi mis un diagnostic système complet (dans le post apres le log console). Ce sont tous les deux des fichiers que jai uploadés sur un site externe pour ne pas rajouter des kilomètres de texte sur ce fil.
Je vais aller retester le script tout à l'heure. Mais quid de mon idée que kernel task envahissait le processeur avec des loops à la con pour éviter la surchauffe parce que le smc défectueux est incapable de donner une température correcte et que du coup il part du principe par sécurité que c'est le maximum ? C'était exactement le même comportement sur mon MacBook Pro, qui était devenu inutilisable sur Lion, alors qu'il n'était même pas tellement chaud. J'avais fait le hack de virer le fichier dans le dossier d'extension, tout était revenu à la normale (et j'utilisais smc fan control). Avec El Capitan, le problème s'est résolu de lui-même.
Alors le démarrage sans extension, si c'est comme le safe boot, déjà testé sans succès. Le log console est à la page précédente.
Jai démarré avant hier en mode verbose et j'ai pu voir des warnings mais ça allait trop vite et je me suis dit qu'il faudrait que je cherche comment choper le log du démarrage d'une façon ou d'une autre mais je n'ai pas re-regardé.
jai aussi mis un diagnostic système complet (dans le post apres le log console). Ce sont tous les deux des fichiers que jai uploadés sur un site externe pour ne pas rajouter des kilomètres de texte sur ce fil.
Je vais aller retester le script tout à l'heure. Mais quid de mon idée que kernel task envahissait le processeur avec des loops à la con pour éviter la surchauffe parce que le smc défectueux est incapable de donner une température correcte et que du coup il part du principe par sécurité que c'est le maximum ? C'était exactement le même comportement sur mon MacBook Pro, qui était devenu inutilisable sur Lion, alors qu'il n'était même pas tellement chaud. J'avais fait le hack de virer le fichier dans le dossier d'extension, tout était revenu à la normale (et j'utilisais smc fan control). Avec El Capitan, le problème s'est résolu de lui-même.
Dernière édition:
