Bonjour à tous,
mon pc se fige (presque) au bout d'un temps qui semble aléatoire, ça
peut être au bout de 1 heure de fonctionnement, ou de plusieurs jours.
le problème apparait que je sois sous environnement X avec kde, ou
simplement en mode console (si je démarre avec un run level spécial qui
ne lance rien en rappaort avec X).
Quand je dis qu'il se fige presque, c'est parce qu'en fait il n'est pas
vraiment figé, c'est plutôt qu'il met un temps incroyablement long à
répondre.
Exemple: je suis sous kde et je fais CTRL+ALT+F1 pour passer en mode
console, et j'attends 10 Mn avant d'avoir le résultat escompté.
Ensuite, je me loggue sur la console, c'est instantané. Je fais un ll, et
j'attends un long moment avant d'avoir la réponse (5mn). Ensuite la même
commande est instantanée.
Si je fais un shutdown, j'attends entre 5mn et 15mn entre chaque
exécution du shutdown (process kill, etc).
Le problème est assez difficile à cerner en fait.
je ne pense pas que X soit en cause (ça arrive sans X aussi, donc...).
Je suis en kernel 2.6.1, j'ai eu ce problème depuis le kernel 2.4.quelque
chose, je ne sais plus, ayant fait tellement de tests et de mises à jour
en espérant que le problème disparaitrait :-)
je n'ai pas de messages particuliers dans les logs.
si je prens le cas de ce week-end, le vendredi soir tout était ok, j'ai
laissé le poste en route sous kde sans rien d'actif, pour voir.
Ce matin, mon horloge kde était à hier 7:14 (un jour de retard!), la
souris était active, mais au premier click j'ai vu l'état "presque-figé".
J'ai rebooté sauvage, et mon horloge Hard était elle bien à l'heure.
Autre piste, quand le problème arrive, je vois mon horloge kde qui
s'affole, si par exemple il est 10heure15, elle passe à 8h45, puis au
bout d'un moment (disons 5mn) à 11h10, puis elle revient à l'heure, etc,
je pense à un problème de cycle de processeur ou un truc dans le genre.
dans le fichier messages, j'ai ceci:
Jan 18 05:56:29 toto -- MARK --
Jan 18 06:16:29 toto -- MARK --
Jan 18 06:36:29 toto -- MARK --
Jan 18 06:47:05 toto syslogd 1.4.1#13: restart.
Jan 18 06:50:34 toto syslogd 1.4.1#13: restart.
Jan 19 07:52:26 toto syslogd 1.4.1#13: restart.
Jan 19 07:52:26 toto kernel: klogd 1.4.1#13, log source = /proc/kmsg
started.
donc aux alentours du 18 à 7h00 et jusqu'au reboot, plus de MARK, est-ce
une autre piste??
ah, j'ai aussi ce message:
Jan 17 09:30:43 toto kernel: Losing too many ticks!
Jan 17 09:30:43 toto kernel: TSC cannot be used as a timesource. (Are you
running with SpeedStep?) Jan 17 09:30:43 web kernel: Falling back to a
sane timesource.
config:
Detected 1993.923 MHz processor.
Using tsc for high-res timesource
Memory: 506444k/515584k available (2051k kernel code, 8308k reserved, 819k
data, 136k init, 0k highmem)
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
Jan 19 07:52:27 toto kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz
stepping 07
agpgart: Detected an Intel 845G Chipset.
...
voilà, merci d'avance à tous ceux qui me donneront une piste, et aux
autres aussi d'ailleurs au moins de m'avoir lu.
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
j'avais aussi au préalable enlevé le process Xprt qui me bouffait du cpu, ce qui m'a permis de croire pendant toute la journée du mardi que c'était ça le problème, vu que ça marchait bien...
(absent mercredi, la machine reste allumée sous kde avec un économiseur actif)
Ce matin, pc figé donc, sous économiseur d'écran GL (ce qui prend aussi pas mal de cpu quand ça tourne...) j'ai viré l'éco d'écran, il ne reste pas grand chose qui tourne...
à suivre, toujours pas de piste réelle :-( merci quand-même à tout le monde.
Bonjour à tous,
suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2
neuves direct de l'emballage...
ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob
matériel sur barrette défectueuse, à priori.
j'avais aussi au préalable enlevé le process Xprt qui me bouffait du
cpu, ce qui m'a permis de croire pendant toute la journée du mardi que
c'était ça le problème, vu que ça marchait bien...
(absent mercredi, la machine reste allumée sous kde avec un économiseur
actif)
Ce matin, pc figé donc, sous économiseur d'écran GL (ce qui prend
aussi pas mal de cpu quand ça tourne...)
j'ai viré l'éco d'écran, il ne reste pas grand chose qui tourne...
à suivre, toujours pas de piste réelle :-(
merci quand-même à tout le monde.
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
j'avais aussi au préalable enlevé le process Xprt qui me bouffait du cpu, ce qui m'a permis de croire pendant toute la journée du mardi que c'était ça le problème, vu que ça marchait bien...
(absent mercredi, la machine reste allumée sous kde avec un économiseur actif)
Ce matin, pc figé donc, sous économiseur d'écran GL (ce qui prend aussi pas mal de cpu quand ça tourne...) j'ai viré l'éco d'écran, il ne reste pas grand chose qui tourne...
à suivre, toujours pas de piste réelle :-( merci quand-même à tout le monde.
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ? Les barettes neuves deffectueuses, ce n'est pas si rare que ça... D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous,
suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2
neuves direct de l'emballage...
ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob
matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ?
Les barettes neuves deffectueuses, ce n'est pas si rare que ça...
D'autre part, l'auto-configuration du BIOS peut jouer des
vilains tours... Si memtest86 donne des erreurs, ajuste les
paramêtres de la RAM pour qu'elle soit la plus lente possible.
S'il y a encore des erreurs, la RAM est deffectueuse.
Sinon, c'est le BIOS.
Si tu n'as aucune erreur de RAM après plusieurs passes complètes
de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème
matériel.
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ? Les barettes neuves deffectueuses, ce n'est pas si rare que ça... D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
Tranquille
De no_spam :
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ?
non, mais l'expérience me suggère que c'est rarement un problème hard en fait lorsqu'il y a un problème sur une machine...
Les barettes neuves deffectueuses, ce n'est pas si rare que ça...
peut-être, mais là déjà les vieilles étaient aussi neuves en fait.
D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode All Tests, aucune erreur.
ce matin, ma station était d'ailleurs OK... je vais la stresser un peu aujourd'hui pour voir si elle se fige presque.
merci de tes conseils qui m'ont permis malgré tout d'enlever la piste matérielle.
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous,
suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2
neuves direct de l'emballage...
ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob
matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ?
non, mais l'expérience me suggère que c'est rarement un problème hard
en fait lorsqu'il y a un problème sur une machine...
Les barettes neuves deffectueuses, ce n'est pas si rare que ça...
peut-être, mais là déjà les vieilles étaient aussi neuves en fait.
D'autre part, l'auto-configuration du BIOS peut jouer des
vilains tours... Si memtest86 donne des erreurs, ajuste les
paramêtres de la RAM pour qu'elle soit la plus lente possible.
S'il y a encore des erreurs, la RAM est deffectueuse.
Sinon, c'est le BIOS.
Si tu n'as aucune erreur de RAM après plusieurs passes complètes
de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème
matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode
All Tests, aucune erreur.
ce matin, ma station était d'ailleurs OK...
je vais la stresser un peu aujourd'hui pour voir si elle se fige presque.
merci de tes conseils qui m'ont permis malgré tout d'enlever la piste
matérielle.
On Thu, 22 Jan 2004 10:54:20 +0100, Tranquille wrote:
Bonjour à tous, suite à mon prob, j'ai changé mardi les 2 barrettes de 256Mo par 2 neuves direct de l'emballage... ce matin jeudi, pc figé presque, comme d'habitude :-((, donc pas prob matériel sur barrette défectueuse, à priori.
Tu as fait un memtest86 avant de dire que les barettes sont bonnes ?
non, mais l'expérience me suggère que c'est rarement un problème hard en fait lorsqu'il y a un problème sur une machine...
Les barettes neuves deffectueuses, ce n'est pas si rare que ça...
peut-être, mais là déjà les vieilles étaient aussi neuves en fait.
D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode All Tests, aucune erreur.
ce matin, ma station était d'ailleurs OK... je vais la stresser un peu aujourd'hui pour voir si elle se fige presque.
merci de tes conseils qui m'ont permis malgré tout d'enlever la piste matérielle.
Le Mardi 20 Janvier 2004 08:11, Tranquille s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
avec ksysguard, je remarque que le process Xprt est à 60% Système et à 35% Utilisateur, nice=0, en charge processeur... par rapport au reste c'est énorme, mais c'est peut-être normal... qu'en pensez-vous?
Je pense qu'il faudrait deja savoir a quoi sert se processus et savoir qui le lance !!
Apres une recherche succinte :
xprt: X print server xprt provides an X server with the print extension and special DDX (Device-Dependent X) implementation. From Debian 3.0r0 APT
A mon avis ton problème viens de là
Tue ce processus et verifie que t'arrives a reprendre la main Si oui, c'etait bien ca
-- @+ Doug [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le Mardi 20 Janvier 2004 08:11, Tranquille s'est exprimé de la sorte sur
fr.comp.os.linux.configuration :
avec ksysguard, je remarque que le process Xprt est à 60% Système et à
35% Utilisateur, nice=0, en charge processeur...
par rapport au reste c'est énorme, mais c'est peut-être normal...
qu'en pensez-vous?
Je pense qu'il faudrait deja savoir a quoi sert se processus et savoir qui
le lance !!
Apres une recherche succinte :
xprt: X print server xprt provides an X server with the print extension and
special DDX (Device-Dependent X) implementation. From Debian 3.0r0 APT
A mon avis ton problème viens de là
Tue ce processus et verifie que t'arrives a reprendre la main Si oui,
c'etait bien ca
--
@+
Doug
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le Mardi 20 Janvier 2004 08:11, Tranquille s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
avec ksysguard, je remarque que le process Xprt est à 60% Système et à 35% Utilisateur, nice=0, en charge processeur... par rapport au reste c'est énorme, mais c'est peut-être normal... qu'en pensez-vous?
Je pense qu'il faudrait deja savoir a quoi sert se processus et savoir qui le lance !!
Apres une recherche succinte :
xprt: X print server xprt provides an X server with the print extension and special DDX (Device-Dependent X) implementation. From Debian 3.0r0 APT
A mon avis ton problème viens de là
Tue ce processus et verifie que t'arrives a reprendre la main Si oui, c'etait bien ca
-- @+ Doug [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
no_spam
On Fri, 23 Jan 2004 11:30:58 +0100, Tranquille wrote:
D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode All Tests, aucune erreur.
Donc, effectivement, ta MMU, ton cache, ton controleur RAM et ta RAM vont bien. Et la config du BIOS ne doit pas être trop mauvaise...
J'y pense: essayes aussi un badblock sur tout tes disques. Il est quand même assez rare qu'une machine se bloque régulièrement sans problème matériel. Ca peut aussi venir d'un driver exotique qui fait une boucle infinie dans une routine ou les IRQ sont désactivées... Mais ça, c'est dur à prévoir... La seule solution: essayer un autre kernel et voir si le problème persiste... C'est un peu la loterie, mais si le problème est logiciel, il ne peut être que dans le kernel, et à priori dans une routine critique. Un crash laisse en général des traces (logs à l'écran voire dans les logs systèmes). Un freeze complet est plus rare et ne laisse aucune trace "visible"... Essaye aussi de laisser ta machine en mode console. Ainsi, si elle crashe, tu auras le message kernel lié à ce crash sur ta console...
On Fri, 23 Jan 2004 11:30:58 +0100, Tranquille wrote:
D'autre part, l'auto-configuration du BIOS peut jouer des
vilains tours... Si memtest86 donne des erreurs, ajuste les
paramêtres de la RAM pour qu'elle soit la plus lente possible.
S'il y a encore des erreurs, la RAM est deffectueuse.
Sinon, c'est le BIOS.
Si tu n'as aucune erreur de RAM après plusieurs passes complètes
de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème
matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode
All Tests, aucune erreur.
Donc, effectivement, ta MMU, ton cache, ton controleur RAM et ta
RAM vont bien. Et la config du BIOS ne doit pas être trop mauvaise...
J'y pense: essayes aussi un badblock sur tout tes disques.
Il est quand même assez rare qu'une machine se bloque régulièrement
sans problème matériel.
Ca peut aussi venir d'un driver exotique qui fait une boucle infinie
dans une routine ou les IRQ sont désactivées...
Mais ça, c'est dur à prévoir...
La seule solution: essayer un autre kernel et voir si le problème
persiste... C'est un peu la loterie, mais si le problème est logiciel,
il ne peut être que dans le kernel, et à priori dans une routine
critique. Un crash laisse en général des traces (logs à l'écran
voire dans les logs systèmes). Un freeze complet est plus rare
et ne laisse aucune trace "visible"...
Essaye aussi de laisser ta machine en mode console.
Ainsi, si elle crashe, tu auras le message kernel lié à ce crash
sur ta console...
On Fri, 23 Jan 2004 11:30:58 +0100, Tranquille wrote:
D'autre part, l'auto-configuration du BIOS peut jouer des vilains tours... Si memtest86 donne des erreurs, ajuste les paramêtres de la RAM pour qu'elle soit la plus lente possible. S'il y a encore des erreurs, la RAM est deffectueuse. Sinon, c'est le BIOS. Si tu n'as aucune erreur de RAM après plusieurs passes complètes de memtest86, alors tu pourras affirmer qu'il n'y a pas de problème matériel.
après 6 passes de memtest86 en mode tests standards et une passe en mode All Tests, aucune erreur.
Donc, effectivement, ta MMU, ton cache, ton controleur RAM et ta RAM vont bien. Et la config du BIOS ne doit pas être trop mauvaise...
J'y pense: essayes aussi un badblock sur tout tes disques. Il est quand même assez rare qu'une machine se bloque régulièrement sans problème matériel. Ca peut aussi venir d'un driver exotique qui fait une boucle infinie dans une routine ou les IRQ sont désactivées... Mais ça, c'est dur à prévoir... La seule solution: essayer un autre kernel et voir si le problème persiste... C'est un peu la loterie, mais si le problème est logiciel, il ne peut être que dans le kernel, et à priori dans une routine critique. Un crash laisse en général des traces (logs à l'écran voire dans les logs systèmes). Un freeze complet est plus rare et ne laisse aucune trace "visible"... Essaye aussi de laisser ta machine en mode console. Ainsi, si elle crashe, tu auras le message kernel lié à ce crash sur ta console...
Jean-Marie Delapierre
Le Mon, 19 Jan 2004 09:25:16 +0100, Tranquille a écrit :
Bonjour à tous, [couic]
Bonjour,
Quel est le type de ta carte graphique et du driver associé ?
Cordialement.
Jean-Marie
Le Mon, 19 Jan 2004 09:25:16 +0100, Tranquille a écrit :
Bonjour à tous,
[couic]
Bonjour,
Quel est le type de ta carte graphique et du driver associé ?
Le Mon, 19 Jan 2004 09:25:16 +0100, Tranquille a écrit :
Bonjour à tous, [couic]
Bonjour,
Quel est le type de ta carte graphique et du driver associé ?
Cordialement.
Jean-Marie
Tranquille
Bonjour à tous, et merci à ceux qui m'ont déjà répondu.
j'ai toujours mon problème... j'ai laissé tourner ma machine ce week-end sous kde, avec rien d'actif, et aucun économiseur. ce matin, avant de toucher à quoi que ce soit, j'ai regardé l'horloge: au lieu de 7h45, j'avais affiché 1h40 (date ok). j'ai fait CRTL+ALT+F1 pour passer en console, ok, puis CTRL+ALT+SUPP pour rebooter, ok, tout s'est bien passé. mais mon horloge n'avait pas été remise à la bonne heure comme ça le fait lorsque j'ai un fige et que j'éteins lourdement... (d'habitude, je vois l'horloge pas à l'heure, je clique un coup quelque part, ça fige, j'éteinds lourdement, et au reboot l'horloge est ok.)
j' vais suivre le conseil de no_spam, et la laisser tourner en mode console pour voir... je vais aussi revenir à un kernel plus ancien au cas où...
ma carte graphique est à base de I845G: 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) au niveau kernel, j'ai l'agp actif avec Intel 440LX/BX/GX, i8xx etc, j'ai le drm actif (je l'avais désactivé ce week-end pour voir mais ça a figé quand-même, donc je le remets maintenant...), avec Intel 830M, 845G, etc. Xfree 4.3 est configuré pour lancer i810...
Avant de rester en console uniquement, est-ce que quelqu'un pense que le paramètre: Enhanced Real Time Clock Support du kernel peut avoir un impact sur mon problème, un rapport avec la maigre piste de l'horloge qui retarde?
bon, merci de m'avoir lu, merci à ceux qui m'aident et aux autres aussi, je vais encore avoir une bonne semaine de tests :-)) -- Fumer tue gravement... Tranquille (ICQ: 342921409)
Bonjour à tous, et merci à ceux qui m'ont déjà répondu.
j'ai toujours mon problème...
j'ai laissé tourner ma machine ce week-end sous kde, avec rien d'actif,
et aucun économiseur.
ce matin, avant de toucher à quoi que ce soit, j'ai regardé l'horloge:
au lieu de 7h45, j'avais affiché 1h40 (date ok).
j'ai fait CRTL+ALT+F1 pour passer en console, ok, puis CTRL+ALT+SUPP pour
rebooter, ok, tout s'est bien passé.
mais mon horloge n'avait pas été remise à la bonne heure comme ça le
fait lorsque j'ai un fige et que j'éteins lourdement...
(d'habitude, je vois l'horloge pas à l'heure, je clique un coup quelque
part, ça fige, j'éteinds lourdement, et au reboot l'horloge est ok.)
j' vais suivre le conseil de no_spam, et la laisser tourner en mode
console pour voir...
je vais aussi revenir à un kernel plus ancien au cas où...
ma carte graphique est à base de I845G:
00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01)
au niveau kernel, j'ai l'agp actif avec Intel 440LX/BX/GX, i8xx etc, j'ai
le drm actif (je l'avais désactivé ce week-end pour voir mais ça a
figé quand-même, donc je le remets maintenant...), avec Intel 830M,
845G, etc.
Xfree 4.3 est configuré pour lancer i810...
Avant de rester en console uniquement, est-ce que quelqu'un pense que le
paramètre:
Enhanced Real Time Clock Support
du kernel peut avoir un impact sur mon problème, un rapport avec la
maigre piste de l'horloge qui retarde?
bon, merci de m'avoir lu, merci à ceux qui m'aident et aux autres aussi,
je vais encore avoir une bonne semaine de tests :-))
--
Fumer tue gravement...
Tranquille (ICQ: 342921409)
Bonjour à tous, et merci à ceux qui m'ont déjà répondu.
j'ai toujours mon problème... j'ai laissé tourner ma machine ce week-end sous kde, avec rien d'actif, et aucun économiseur. ce matin, avant de toucher à quoi que ce soit, j'ai regardé l'horloge: au lieu de 7h45, j'avais affiché 1h40 (date ok). j'ai fait CRTL+ALT+F1 pour passer en console, ok, puis CTRL+ALT+SUPP pour rebooter, ok, tout s'est bien passé. mais mon horloge n'avait pas été remise à la bonne heure comme ça le fait lorsque j'ai un fige et que j'éteins lourdement... (d'habitude, je vois l'horloge pas à l'heure, je clique un coup quelque part, ça fige, j'éteinds lourdement, et au reboot l'horloge est ok.)
j' vais suivre le conseil de no_spam, et la laisser tourner en mode console pour voir... je vais aussi revenir à un kernel plus ancien au cas où...
ma carte graphique est à base de I845G: 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) au niveau kernel, j'ai l'agp actif avec Intel 440LX/BX/GX, i8xx etc, j'ai le drm actif (je l'avais désactivé ce week-end pour voir mais ça a figé quand-même, donc je le remets maintenant...), avec Intel 830M, 845G, etc. Xfree 4.3 est configuré pour lancer i810...
Avant de rester en console uniquement, est-ce que quelqu'un pense que le paramètre: Enhanced Real Time Clock Support du kernel peut avoir un impact sur mon problème, un rapport avec la maigre piste de l'horloge qui retarde?
bon, merci de m'avoir lu, merci à ceux qui m'aident et aux autres aussi, je vais encore avoir une bonne semaine de tests :-)) -- Fumer tue gravement... Tranquille (ICQ: 342921409)
Arnaud Gomes-do-Vale
Tranquille writes:
Avant de rester en console uniquement, est-ce que quelqu'un pense que le paramètre: Enhanced Real Time Clock Support du kernel peut avoir un impact sur mon problème, un rapport avec la maigre piste de l'horloge qui retarde?
J'en doute. J'aurais plus tendance à soupçonner l'ACPI. Compile un noyau sans ACPI (ni APIC, tant qu'on y est) et regarde ce que ça donne.
-- Arnaud Gomes-do-Vale -*-*-*- http://www.glou.org/~arnaud/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- En savoir plus sur GNU/Linux : http://www.linux-france.org/
Tranquille <Tranquille@cnafmail.fr-XXX> writes:
Avant de rester en console uniquement, est-ce que quelqu'un pense que le
paramètre:
Enhanced Real Time Clock Support
du kernel peut avoir un impact sur mon problème, un rapport avec la
maigre piste de l'horloge qui retarde?
J'en doute. J'aurais plus tendance à soupçonner l'ACPI. Compile un
noyau sans ACPI (ni APIC, tant qu'on y est) et regarde ce que ça
donne.
--
Arnaud Gomes-do-Vale -*-*-*- arnaud@carrosse.frmug.org
http://www.glou.org/~arnaud/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
En savoir plus sur GNU/Linux : http://www.linux-france.org/
Avant de rester en console uniquement, est-ce que quelqu'un pense que le paramètre: Enhanced Real Time Clock Support du kernel peut avoir un impact sur mon problème, un rapport avec la maigre piste de l'horloge qui retarde?
J'en doute. J'aurais plus tendance à soupçonner l'ACPI. Compile un noyau sans ACPI (ni APIC, tant qu'on y est) et regarde ce que ça donne.
-- Arnaud Gomes-do-Vale -*-*-*- http://www.glou.org/~arnaud/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- En savoir plus sur GNU/Linux : http://www.linux-france.org/
Tranquille
De Arnaud Gomes-do-Vale :
... Compile un noyau sans ACPI (ni APIC, tant qu'on y est) et regarde ce que ça donne.
Bonjour à tous, ça fait deux jours que ma machine ne plante pas... je dois tenir le bon bout!!! dernières manips faites: désactivation de l'acpi dans le kernel: ça plantait toujours. désactivation de l'apm: idem désactivation de local-apic support: depuis ça à l'air d'aller mieux.
D'ailleurs, je n'ai plus non plus ces messages: Losing too many ticks! TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource.
Pourrait-il y avoir un rapport entre local apic et tsc???
maintenant, je vais rester comme ça jusqu'à lundi pour voir si plante vraiment plus, ensuite je vais remettre l'option pour être sûr... et tout remonter petit à petit pour voir...
merci de votre aide à tous, et si c'est bien le local-apic qui fout le "bordel", est-ce que je devrais faire quelque chose, signaler quelque part???
Bonjour à tous,
ça fait deux jours que ma machine ne plante pas...
je dois tenir le bon bout!!!
dernières manips faites:
désactivation de l'acpi dans le kernel: ça plantait toujours.
désactivation de l'apm: idem
désactivation de local-apic support: depuis ça à l'air d'aller mieux.
D'ailleurs, je n'ai plus non plus ces messages:
Losing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?)
Falling back to a sane timesource.
Pourrait-il y avoir un rapport entre local apic et tsc???
maintenant, je vais rester comme ça jusqu'à lundi pour voir si plante
vraiment plus, ensuite je vais remettre l'option pour être sûr... et
tout remonter petit à petit pour voir...
merci de votre aide à tous, et si c'est bien le local-apic qui fout le
"bordel", est-ce que je devrais faire quelque chose, signaler quelque part???
Bonjour à tous, ça fait deux jours que ma machine ne plante pas... je dois tenir le bon bout!!! dernières manips faites: désactivation de l'acpi dans le kernel: ça plantait toujours. désactivation de l'apm: idem désactivation de local-apic support: depuis ça à l'air d'aller mieux.
D'ailleurs, je n'ai plus non plus ces messages: Losing too many ticks! TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource.
Pourrait-il y avoir un rapport entre local apic et tsc???
maintenant, je vais rester comme ça jusqu'à lundi pour voir si plante vraiment plus, ensuite je vais remettre l'option pour être sûr... et tout remonter petit à petit pour voir...
merci de votre aide à tous, et si c'est bien le local-apic qui fout le "bordel", est-ce que je devrais faire quelque chose, signaler quelque part???
