plantage emerge

Le
pascal
Salut,

Depuis quelques temps,sur ma gentoo, sur certains emerges, j'ai ce
message (avec dmesg)
: MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 2: 940040000000017a

Ce serais le cache du processeur qui serait HS ! Mais je n'ai pas beaucoup
plus d'info.

Un problème de config sur gcc pourrais faire la même chose ? Ou c'est
vraiment matériel ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas S.
Le #1895727
Salut,


Bonsoir,

Depuis quelques temps,sur ma gentoo, sur certains emerges, j'ai ce
message (avec dmesg)
: MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 2: 940040000000017a


Quel est le processeur utilisé et quelle est la version du noyau?

--
Nicolas S.

pascal
Le #1895723
On Wed, 04 Jul 2007 00:34:03 +0200, Nicolas S. wrote:

Salut,


Bonsoir,

Depuis quelques temps,sur ma gentoo, sur certains emerges, j'ai ce
message (avec dmesg)
: MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 2: 940040000000017a


Quel est le processeur utilisé et quelle est la version du noyau?


Athlon XP 2600 kernel 2.6.20-gentoo-r8.


Sebastiaan 'CrashandDie' Lauwers
Le #1895721
pascal wrote:
On Wed, 04 Jul 2007 00:34:03 +0200, Nicolas S. wrote:
Depuis quelques temps,sur ma gentoo, sur certains emerges, j'ai ce
message (avec dmesg)
: MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 2: 940040000000017a




Il serait franchement intéressant de savoir depuis quand, et quels
changement ont été fait sur le système lorsque c'est apparu...

Aussi, durant quelle phase de l'emerge est-ce que cela apparait ?
Compilation, precheck, postinstall, etc...

Quel type de paquets? (binaires, source, bla bla)

Quel est le processeur utilisé et quelle est la version du noyau?
Athlon XP 2600 kernel 2.6.20-gentoo-r8.



Une nouvelle version du noyau peut-être ? Je sais qu'il n'y a rien de
unmasked après la 2.6.20-r8, mais est-ce que c'est après une mise à jour
du kernel que c'est apparu ?

Aussi, est-ce que l'erreur se produit régulièrement ? C'est à dire,
est-ce que dmesg est floodé de messages de ce type là, ou juste une ou
deux fois ?

Pour vérifier ce genre de choses, il faudrait swapper le CPU avec un
autre, la série des Athlon XP n'est pas dûre à trouver, donc voir le
magasin du coin, ou le PC du voisin pour vérifier si le problème vient
bien du CPU ou d'autre chose.

HTH,

S.



Nicolas S.
Le #1895713

: MCE: The hardware reports a non fatal, correctable incident occurred on
CPU 0.
Bank 2: 940040000000017a
Quel est le processeur utilisé et quelle est la version du noyau?



Athlon XP 2600 kernel 2.6.20-gentoo-r8.


Bon, j'avoue ne pas avoir suivi les dernières évolutions du kernel et
avoir la flemme de chercher.
Il est difficile de dire d'où cela vient exactement. Il s'agit bien d'un
signalement de problème du côté des registres processeur. Aux dernières
nouvelles (tout début de la branche 2.6), le support AMD était bogué.

En premier lieu, il peut être bon de mettre à jour le BIOS (si MàJ il y a).
S'assurer que la température n'est pas trop élevée (je soupçonne
l'ordinateur d'être un portable) et descendre la fréquence du processeur
s'il est overclocké.
Ensuite, je te conseille de tester avec un noyau "vanilla".

N'hésite pas à mettre ton kernel à jour au fur et à mesure que les
nouvelles versions sortent sous Gentoo.

Le côté désagréable est que ce message va te remplir les logs. Je te
conseille d'installer le paquet mcelog, histoire d'y voir plus clair.

Cordialement,

--
Nicolas S.



pascal
Le #1895712
On Wed, 04 Jul 2007 11:39:52 +0200, Sebastiaan 'CrashandDie' Lauwers
wrote:


Il serait franchement intéressant de savoir depuis quand, et quels
changement ont été fait sur le système lorsque c'est apparu...

Aussi, durant quelle phase de l'emerge est-ce que cela apparait ?
Compilation, precheck, postinstall, etc...



lors de la compilation.

Quel type de paquets? (binaires, source, bla bla)


Toujours sur des sources. Quoi que, j'ai eut des crashs sur php avec
Album2.


Quel est le processeur utilisé et quelle est la version du noyau?
Athlon XP 2600 kernel 2.6.20-gentoo-r8.



Une nouvelle version du noyau peut-être ? Je sais qu'il n'y a rien de
unmasked après la 2.6.20-r8, mais est-ce que c'est après une mise à jour
du kernel que c'est apparu ?


Je ne peut plus mettre à jour certains paquets, dont gcc et la glibc.
J'avais des freeze sur Windows (les jeux....) et je me suis pas
inquiété ... Et cela à pris d'un coup. Un jour, j'ai eut des services
qui plantait au démarrage. J'ai enlevé 2/3 cartes, refait quelques manip
sur les modules, et lors du sync suivant et du emerge -u wolrd, certains
paquets plantaient avec le message sig-fault.



Aussi, est-ce que l'erreur se produit régulièrement ? C'est à dire,
est-ce que dmesg est floodé de messages de ce type là, ou juste une ou
deux fois ?


Non, toujours 2 cases mémoires, et toujours les mêmes. Quelques dump des
registres (rare). Parfois en insistant, la compilation passe !


Pour vérifier ce genre de choses, il faudrait swapper le CPU avec un
autre, la série des Athlon XP n'est pas dûre à trouver, donc voir le
magasin du coin, ou le PC du voisin pour vérifier si le problème vient
bien du CPU ou d'autre chose.


il n'y en a plus ! Sur le marché de l'occase, c'est 80¤ ! Il faudrait
que je démonte un des PC du bureau.


HTH,

S.




Sebastiaan 'CrashandDie' Lauwers
Le #1895709
pascal wrote:

lors de la compilation.


Utilisation intensive des registres et du cache.

Toujours sur des sources. Quoi que, j'ai eut des crashs sur php avec
Album2.


Album2, si y'a pas mal de trucs à gérer, un disque dûr pas spécialement
rapide, ça va remplir les caches aussi...

Je ne peut plus mettre à jour certains paquets, dont gcc et la glibc.
J'avais des freeze sur Windows (les jeux....) et je me suis pas
inquiété ... Et cela à pris d'un coup. Un jour, j'ai eut des services
qui plantait au démarrage. J'ai enlevé 2/3 cartes, refait quelques manip
sur les modules, et lors du sync suivant et du emerge -u wolrd, certains
paquets plantaient avec le message sig-fault.


(segfault -- segmentation fault)

Le fait que le problème se retrouve autant sous Windows que sous Gentoo
indique bel et bien un défaut matériel, et je trouve assé bizarre que
vous ne l'ayez pas mentionné plus tôt, étant donné que le problème ne se
pose pas QUE sous Gentoo. Cependant, je me dois de remarquer une chose:
le climat. Je ne sais pas où vous êtes, mais les AMD, ça chauffe.

Spécialement durant les jeux, et la compilation, j'ajouterais même.
Prenez un gros ventilo (vous savez, le truc qu'on a dans le salon, et
que le chien déteste), ouvrez votre boitier et placer le dedans,
puissance max. Réessayez.

Non, toujours 2 cases mémoires, et toujours les mêmes. Quelques dump des
registres (rare). Parfois en insistant, la compilation passe !


Ca, ça indique des transistos crâmés.

il n'y en a plus ! Sur le marché de l'occase, c'est 80¤ ! Il faudrait
que je démonte un des PC du bureau.


Je pense qu'on connait tous deux le résultat. Soit vous tomberez sur une
série qui surchauffe moins, et vous croirez le CPU mort, soit le CPU est
mort.

Cependant, juste pour être sûr, reprennez votre liveCD de Gentoo, et
passez le en mode Memtest pendant une nuit, ça ne fera pas de mal
d'exclure la validité de la RAM, tant qu'on y est.

HTH,

S.

Sebastiaan 'CrashandDie' Lauwers
Le #1895708
Nicolas S. wrote:

Le côté désagréable est que ce message va te remplir les logs. Je te
conseille d'installer le paquet mcelog, histoire d'y voir plus clair.


Le côté désagréable est surtout qu'il y a bon nombre de paquets qui ne
veulent plus se compiler du tout...

Une chose qu'il vient de mentionner, c'est qu'en plus du message sympa
dans le dmesg, la compilation plante avec un segfault.

Cordialement,


De plus, les gentoo-sources n'ont absolument plus rien à envier à la
glace à la vanille. Bien au contraire même. Vanilla a vu son taux de
contributeurs chutter fortement les derniers temps, beaucoup estimant
que leur travail était inutile, vu qu'ils faisaient pareil kelesautres...

Je propose une mention sur une défaillance matérielle, qu'elle soit dûe
à la surchauffe, ou à un réel problème de rupture, cela va de soit.

On fait un pari ?

S.

pascal
Le #1895707
On Wed, 04 Jul 2007 22:40:03 +0200, Sebastiaan 'CrashandDie' Lauwers
wrote:


Cependant, juste pour être sûr, reprennez votre liveCD de Gentoo, et
passez le en mode Memtest pendant une nuit, ça ne fera pas de mal
d'exclure la validité de la RAM, tant qu'on y est.

HTH,

S.


Ok, je testerai ça.

Pour info, je suis dans le sud ouest. Il a peu être chauffé l'été
dernier !?

Merci, @+

pascal
Le #1895706
On Wed, 04 Jul 2007 22:43:46 +0200, Sebastiaan 'CrashandDie' Lauwers
wrote:


Je propose une mention sur une défaillance matérielle, qu'elle soit dûe
à la surchauffe, ou à un réel problème de rupture, cela va de soit.

On fait un pari ?

S.


Je vais essayer en changeant le processeur. C'est un PC de bureau, et
j'ouvre le boitier l'été. Ca chauffe trop autrement.

Merci, @+

Nicolas S.
Le #1895705

Le côté désagréable est surtout qu'il y a bon nombre de paquets qui ne
veulent plus se compiler du tout...


Usenet est asynchrone.

Une chose qu'il vient de mentionner, c'est qu'en plus du message sympa
dans le dmesg, la compilation plante avec un segfault.


Crosscompilation?

De plus, les gentoo-sources n'ont absolument plus rien à envier à la
glace à la vanille. Bien au contraire même. Vanilla a vu son taux de
contributeurs chutter fortement les derniers temps, beaucoup estimant
que leur travail était inutile, vu qu'ils faisaient pareil kelesautres...


Je n'ai fait pas fait mention du paquet Gentoo et ne te ferai pas
l'affront de te présenter les nombreux mirroirs où trouver un kernel
vanille.

Je propose une mention sur une défaillance matérielle, qu'elle soit dûe
à la surchauffe, ou à un réel problème de rupture, cela va de soit.

On fait un pari ?


J'annonce un 7.

Je suggère simplement à l'OP de pousser un peu les tests, à moins bien
sûr qu'il n'ait pris une bonne extension de garantie. :-)

--
Nicolas S.

Publicité
Poster une réponse
Anonyme