Interpréter un Kernel Panic

[Thierry GEFARD]

Bonjour,
J'en ai marre, je viens de faire la Maj X.1.5 après avoir défragmenté ma partition avec speed disk 6 et réparé les erreurs trouvées par Norton disk Doctor.
Et voila de nouveau les "Kernel Panic" qui reviennent.
Je précise que je n'ai jamais bidouillé le terminal, je n'utilise OS X que de façon cool (video avec Imovie, gravage de video cd avec Toast.

Maj faite hier et aujourd'hui un Kernel Panic :
"Panic (cpu 0) : we can't get a mutex interlock lock on mutex = lock".
Puis des lignes de codes et à la fin :
Debug (Panic) waiting for remote debugger.
Connection :
Option Type
Continue "C"
reboot "R"

Mais en fait il n'est pas possible de faire quelque chose sinon redémarrer malgré le message qui laisse entendre qu'un reboot ou une continuation serait possible.

Quelqu'un peut-il me dire ce que veut dire le début du message "we can't get a mutex ...."

Peut-être trouverai-je la raison de ces Kernel Panic agaçants ?

Merci de vos réponses.

A +

 

[benR]

une recherche google permet de trouver quelques pistes...
Selon qq1, il pourrait s'agir d'un probleme d'ATA....

ICI

 

[Le Gognol]

'

Défragmenter le volume de boot de X ne sert quasiment à rien, et en tout cas ne répare rien, tandis que les réparations proposées par Norton peuvent je crois avoir des effets néfastes sur le système (il n'est pas prévu pour X au départ). Assure toi en premier lieu que tes premiers kernels panic ne sont pas apparus suite à des opérations de ce genre. Si c'est le cas, je te conseille une réinstallation (tu sauves les dossiers Users, Aplications, Library, différentes méthodes ont été évvoquées sur ces forums) et tu repars à 0, sans utiliser à l'avenir ces outils qui créént plus de problèmes que de solutions.

'+

 

[maousse]

Pour l'espace disque, j'ai en général mon disque assez rempli, et je n'ai jamais eu de kernel panic à cause de ça... J'ai même déjà eu une alerte comme quoi il n'y avais plus assez de mémoire et que je devais quitter des applications pour libérer de la mémoire !

Mais ça n'a pas planté...

 

[matmiev]

Bonne remarque : avant on avait une petite bombe sans autre explication, désormais on a un charabia à interpréter...

Je viens d'avoir mon premier Kernel Panic :
panic (cpu0) : inid died

et je n'ai aucune idée de ce que cela signifie ! Enfin si, je pense que c'est suite un pb de RAM (256 Mo pourtant) et d'espace disque insuffisant (3 Go). De toute façon, je réinstalle tout (cf. post "Mac OS X doit être rebooter plusieurs fois par jour!") et après ça marchera beaucoup mieux.


Sinon, pour Norton, je doute effectivementde sa réelle amélioration (même avec os x profile 3.1), et tout le monde le déconseille (il vaut mieux un fsck ou autre)

 

[matmiev]

Oui donc, y-a-t-il des "interpréteurs" (logiciels ou physiques !) des kernel panic ?

 

[Le Gognol]

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par matmiev:
je pense que c'est suite un pb de RAM (256 Mo pourtant) et d'espace disque insuffisant (3 Go)<HR></BLOCKQUOTE>

Ca m'étonnerait, y'a de la marge quand même...

'+

[08 juin 2002 : message édité par Le Gognol]

 

[W.S]

Première piste : http://docs.info.apple.com/article.html?artnum=106227

 

[matmiev]

Hello !

Je ne voulais pas relancer la polémique de mon disque qui scrounche et qui fait tout planter, cela a déjà été évoqué dans "Mac OS X doit être rebooter plusieurs fois par jour!", et mon G4 survit avec "Turbomem" qui tourne en permanance derrière pour éviter tout plantage…

Bref, ce que je voulais juste savoir, c'est s'il existait un résumé détaillé des différents kernel panic (je sais ça n'arrive pas souvent, mais lorsque ça vient, on aimerait savoir pourquoi)

 

[Thierry GEFARD]

Merci pour vos premières réponses.
Mais de guerre lasse j'ai effacé ma partition OS X depuis OS 9.22 puis réinstallé OS X 1.3 puis 1.4.
Pour le moment je vais tourner avec une install mini : toast 5 pour graver mes videos CD et AW 6.
On verra.
Effectivement, j'ai installé un deuxième DD de 6 Go en slave et formaté en mac OS étendu mais ceci la semaine dernière.
Comment savoir si c'est vraiement lui d'autant que j'ai eu une demi douzaine de Kernel Panic et jamais avec le même message de début.

Je vois que je ne suis pas le seul à vouloir comprendre les messages cabalistiques d'un Kernel Panic.

J'ai lu les différentes explications données en anglais mais je ne suis pas plus avancé.
Ne pourrions-nous pas tenter de regrouper ensemble tous les messages de Kernel Panic en une base de données mentionnant les remèdes ou causes détectés ?

Sous OS classic les "erreurs type .." ont été répertoriées et nous permettent de trouver la cause de notre problème plus facilement.

 

[matmiev]

article traitant des Kernel Panic et de 10.1.5
http://www.macosx.be/article.php3?id_article=27

Sinon, un référencement des Kernel Panic serait une bonne initiative (je pense qu'il existe des personnes compétentes pour ce genre de choses…)

 

[nekura]

Il n'y a pas énormément de choses à tirer de ces messages "kernel panic", à première vue. Ces messages donnent la raison "finale" du plantage, mais pas grand-chose sur ce qui est à l'origine du problème.

Je vais essayer de "traduire" l'intitulé de ces kernels panic, mais comme vous allez le voir, ça ne mène pas à grand-chose.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>init died<HR></BLOCKQUOTE>
init est un process unix très particulier.
C'est un des premiers (voire le premier) à être démarré sur la machine après la phase de boot et continue à tourner jusqu'à l'arrêt de la machine. Il est le "père" de tous les autres processus du système (ou du moins d'une très très large partie d'entre eux, je crois que cela dépend de l'OS).
Il prend en charge différentes tâches d'initialisation, et relance automatiquement certains processus lors de leur mort. C'est également lui qui gère l'arrêt de tous les processus lorsqu'on arrête, reboote ou passe en mode "mono-utilisateur" la machine.

Ce process ne DOIT PAS mourir. En théorie, d'ailleurs, je pense qu'il ne peut pas... sauf problème majeur rencontré par le kernel, ce qui est visiblement le cas ici.

Le fait que ce processus meure n'est donc qu'un symptôme, et n'est pas l'origine du problème à proprement parler.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>we can't get a mutex interlock lock on mutex = lock<HR></BLOCKQUOTE>

Un mutex ("MUTual EXclusion") est une technique de programmation répandue qui permet de protéger l'accès à certaines ressources.

Il s'agit d'une espèce de verrou qui évite que plusieurs programmes fassent des opérations simultanées sur une ressource de l'ordinateur qui ne supportent pas d'accès simultanés. Par exemple, deux programmes ne peuvent pas écrire exactement en même temps sur le disque ; l'un des deux devra attendre que l'autre termine son bloc d'écriture.

Un programme qui désire faire une opération sur ce type de ressource doit demander le verrou, c'est à dire obtenir le droit exclusif de travailler sur cette ressource.
Si le verrou n'est pas libre, le programme restera bloqué au niveau de la demande jusqu'à ce que le programme qui l'utilise actuellement le libère.

Ce message indique à mon avis que le noyau n'a pas réussi à obtenir un verrou baptisé "lock" (très original) au terme d'un certain délai, alors qu'il aurait dû y arriver d'une manière ou d'une autre.
Là encore, symptôme et non cause du problème...

Pour espérer en savoir davantage sur la raison profonde de ces kernels panics, il faut se pencher sur le "stack trace" qui est indiqué après le message ; cet ensemble de données peut donner au développeur d'un programme un indice sur ce qui s'est passé. Mais pour le commun des mortels, ça reste un peu opaque

[17 juin 2002 : message édité par Nekura]