Gel de temps-à-autre

Support Debian
#1

Bonsoir,

Sur mon PC Debian, et, lors de quelques actions spécifiques, tout semble se figer, à chaque fois. Par exemple, lorsque j’utilise l’équivalent de Thunderbird pour Debian, et que j’envoie un e-mail (signé), la fenêtre (et l’application) se fige, et la seule manière de la fermer est de tuer le processus, voire les processus. Le problème est bien mis en évidence lorsque j’écoute de la musique (quel que soit le support), et que l’application, par exemple pour envoyer des e-mails, se fige. En effet, la musique boucle'' alorstrès lentement,’’ c’est-à-dire que l’endroit de lecture courant du morceau (en cours) est répété pendant par exemple 20 ou 30 fois, avant de passer au dixième de seconde suivant, le tout donnant une musique lue comme si elle était très ralentie, et répétée, d’une manière très désagréable.
Notez que la musique se lit parfaitement lorsqu’aucune opération de ce type n’est lancée.

Cela est assez handicapant, et j’ai expérimenté cela avec Ubuntu, quelle que soit la version, et Debian, en essayant plusieurs noyaux, et en étant toujours le plus à jour. Je pense que mon matériel n’est pas entièrement pris en charge. Pourtant, ce n’est plus tout nouveau. Voici ce qui importe de ma config:

Intel Core 2 Quad Q9450@2.66Ghz * 4,
Asus P5K/EPU.

Merci de me dire quoi faire: après avoir essayé plusieurs distributions, je ne comprends pas pourquoi un tel problème, récurrent. Pourtant, mon BIOS est à jour!

#2

Salut,

Assures toi à l’aide d’un memtest prolongé que tu n’as pas de mémoire défaillante.

#3

Merci pour une réponse aussi rapide. Je l’ai malheureusement déjà fait (laissé tourner 24h), et ça n’a rien donné de problématique.

En plus, sous d’autres OS non Linux, je n’ai pas de souci!

#4

mhmm dificile de deviner de cette manière.

si tu commençais par nous dire ce que tu a fait pour dénicher le problème?

en complement pourait on avoir:

ta distribution actuel etch,lenny,sid,unstable?
paquet uniforme , c’est a dire que tous apartien a etch OU a lenny ? (donc pas de mélange)
noyaux, soft ouver ? deamon
sa gèle ok mai qu’elle son tes ressource disponible, charge,cpu,memoire,dd avant et après le frez?

le fait que sa ce répettre semble indiquer une charge importante. gnom, kde ?

bref t’a deviner qu’on peu x pas deviner sans plus d’info :smt006

#5

Salut,

L’autre OS dont tu parles n’utilises pas la mémoire mais préfères “swapper” ce qui fait qu’il n’utilises que rarement les moyens mis à sa disposition :smiley:

#6

[quote=“panthere”]mhmm dificile de deviner de cette manière.

si tu commençais par nous dire ce que tu a fait pour dénicher le problème?

[/quote]
Quels infos voulez-vous?

[quote]ta distribution actuel etch,lenny,sid,unstable?
[/quote]
lenny pour l’instant.

Tout est uniforme.

Je n’avais rien installé d’autre que Debian (donc juste après l’installation) que ça buguait déjà. Les deamons sont donc les deamons habituels, et il n’y a aucun soft ouvert. J’ai un noyau 2.6.26-2-686.

avant, pendant, ou durant le freez, la charge cpu est <1%, pareil pour le dd (swap non utilisé non plus). Cependant, la mémoire semble être plus fort utilisée, comme l’indique un témoin que j’ai mis dans la barre ``des tâches.’’

Gnome.

[quote]
bref t’a deviner qu’on peu x pas deviner sans plus d’info :smt006[/quote]

J’espère que c’est suffisant. Merci.

#7

[quote=“ggoodluck47”]Salut,

L’autre OS dont tu parles n’utilises pas la mémoire mais préfères “swapper” ce qui fait qu’il n’utilises que rarement les moyens mis à sa disposition :smiley:[/quote]
C’est bien possible! Ca doit être un problème de mémoire vive.

#8

Re,

Si tu as laissé memtest tourner une journée on peut exclure un problème de mémoire.

Alimentation ? Température ? Température de la carte graphique ?

#9

[quote=“ggoodluck47”]Re,

Si tu as laissé memtest tourner une journée on peut exclure un problème de mémoire.

Alimentation ? Température ? Température de la carte graphique ?[/quote]

Tout va bien, je scrute constamment les infos de sensors.

Par contre, memtest ne me reporte aucune erreur lors du test, lorsque je choisis ``old version.’’ En effet, les deux autres choix (version courante, non SMP, ou version courante, SMP expérimentale), buguent chez moi: la version non SMP reboot après quelques secondes, et l’autre bloque, et m’oblige à éteindre le pc!

#10

Re,

Avant de te répondre, je viens de faire un test “memtest86+” sur un Intel Celeron 700 Mhz (et donc pas de première jeunesse) et il fonctionne parfaitement (pas très vite :smiley: )

Dans un premier temps vérifies que tes barrettes sont bien enclenchées.
Quelque soit le memtest il devrait passer s’il passe chez moi sur une antiquité.

#11

Ok pour les barrettes: tout est OK. Pourquoi l’ancienne version fonctionnerait-elle, alors que la nouvelle reboot? Je suppose que la version expérimentale SMP est susceptible de buguer, d’où le freeze.

#12

Re,

Parce que la nouvelle version est plus rigoureuse que l’ancienne et qu’elle ne laisse pas passer les erreurs.
Tu vas devoir prendre l’habitude que c’est du côté de l’utilisateur que sont les erreurs, tu n’es plus sous Windows :smiley:
S’il y avait un bug dans memtest86+ depuis le temps qu’il est sorti, cela se saurait !

#13

[quote=“ggoodluck47”]Re,

Parce que la nouvelle version est plus rigoureuse que l’ancienne et qu’elle ne laisse pas passer les erreurs.
Tu vas devoir prendre l’habitude que c’est du côté de l’utilisateur que sont les erreurs, tu n’es plus sous Windows :smiley:
S’il y avait un bug dans memtest86+ depuis le temps qu’il est sorti, cela se saurait ![/quote]

Je n’ai pas critiqué memtest86+: je sais que sa fiabilité est réputée. J’ai l’habitude avec Linux. Vous m’avez mal compris. Ce qui m’inquiète, c’est ce redémarrage.

#14

Re,

Une fois altérée une seule position de mémoire peut avoir pris une valeur telle que la réaction du programme est imprévisible : Alors pourquoi ne provoquerait-elle pas un reboot par altération d’une séquence ?
Ce programme se chargeant seul au démarrage se retrouve dans les mêmes positions de mémoire à peu près à coup sur : même cause = mêmes effets :smiley:

#15

C’est fort plausible. Pratiquement, y a-t-il une solution?

#16

Re,

Si ta mémoire est en plusieurs barrettes, ce que je préconise, faire des essais pour déterminer la fautive et la remplacer . Si aucune ne révélait fautive soupçonner l’incompatibilité si elle ne sont pas du même fabricant !

#17

J’y avais déjà pensé :frowning: Dommage que cela ne soit pas si simple. Elles ont exactement les m^emes références, et proviennent du m^eme constructeur, achetées en m^eme temps chez le m^eme marchand, et fonctionnent bien individuellement. :frowning:

#18

Salut,

J’ai épuisé mon expérience en la matière :slightly_smiling: Désolé.

#19

Dommage. :frowning:

#20

Quelques infos supplémentaires:

Après plusieurs vérifications, j’ai réalisé que le blocage de Thunderbird n’était pas seulement dépendant de l’utilisation du CPU. Cependant, je remarque que, quand, par exemple Thunderbird envoie un mail, et que d’autres programmes sont en cours d’exécution, et puis que Thunderbird gèle, il se passe quelque chose de magique avant le gel complet: l’utilisation mémoire augmente de plus en plus (exemple: 19 -> 20 -> 21 -> 22), sans arrêt. Cela devient tellement important que le Swap est utilisé partiellement avant que mes 3.2 (en réalité 4, mais comme je suis sur du x86, mes 4*1024 ne sont pas supportés entièrement) Go soient utilisés.

Quand mémoire'' est haut (même si, lorsque je regarde dans le moniteur système, elle n'est pas autant utilisée qu'indiqué dans la barredes tâches’’), et qu’elle atteint une pointe d’utilisation, Thunderbird est directement fermé par l’OS. La lecture de la musique retrouve un caractère plus ou moins normal. Malheureusement, ce n’est pas ce que je désire!

Merci.