web123 wrote:Je vais faire de même pour xorg-x11-drv-mga.

Ben ça ne marche pas. Freeze au bout de quelques heures.

web123 wrote:Le rapport de bug le plus proche que j'ai vu de mon problème :
https://bugzilla.redhat.com/show_bug.cgi?id=2831611

Ben, pas de solution...

Lorsque le 2.6.24 sera un peu stabilisé, je ferais un essai.

Le mieux est en effet de se reporter sur un noyau plus stable, si vous avez la chance que le -42 fonctionne.

Telimektar wrote:A noter que la fréquence des freezes a grandement diminuée depuis que j'utilise les options du noyau :
nohz=off highres=off clocksource=acpi_pm pnpapic=off

Avec ces options de noyau, je n'ai plus aucun freeze, merci Telimektar ! Je peux hiberner sans aucun souci en plus, grâce à Tux on Ice (anicennement Suspend2) -- j'utilise le noyau 2.6.23.1-49_1.cubbi_tuxonice.fc8, compilé par Matthias Hensler http://mhensler.de/swsusp

J'ai installé kernel-2.6.23.8-61.fc8 et ça semble bien se passer.
http://koji.fedoraproject.org/koji/buildinfo?buildID=24904
Evidemment, il faudra attendre quelques jours pour conclure tant de "freeze" se déclenche rarement chez moi.

Notons cette ligne dans le changelog :

* Mon Nov 19 2007 Chuck Ebbert <XXXX@XXXX>
- libata: fix resume on some systems

web123 wrote:J'ai installé kernel-2.6.23.8-61.fc8

Ça plante toujours...

Désolé de revenir à la charge, mais rien de nouveau ? Car cela fait une mauvaise publicité pour la fedora 8, cette histoire de freeze aléatoire 🙁

Salut
Je comprend votre problème...
Mais il ne faut pas prendre votre cas pour une généralité.
Ma F8 n'a jamais freezé avec des uptimes de plusieurs jours. Et je suis persuadé que c'est le cas pour l'immense majorité des utilisateurs.
Certe si problème il y a, il faut le déterminer et le corriger, mais de là à laisser entendre que F8 est instable et que c'est insupportable pour tout le monde, il y a un pas de géant...

philippe83 wrote:Salut
Je comprend votre problème...
Mais il ne faut pas prendre votre cas pour une généralité.

Au moins 3 personnes (dont un modérateur) a été confronté à ce problème de freeze, réglé par une rétrogradation de version du noyau. C'est donc qu'il y a un problème avec la dite version du noyau.

Ma F8 n'a jamais freezé avec des uptimes de plusieurs jours. Et je suis persuadé que c'est le cas pour l'immense majorité des utilisateurs.

Et alors ? Cela ne veut rien dire. Des personnes se sont plaintes sur d'autres distros qu'elles avaient des freeze et d'autre personnes de répondre le même genre de réponse qu'au dessus.

Tout dépend de la version utilisé. N'utilisant plus les versions 32 bits des distros, étant donné que 99,99% de processeurs qui sortent actuellement sont des 64 bits, autant regarder vers l'avenir et ne plus rester avec une architecture qui sera plus supporté d'ici quelques années, 3 ou 4 à vue de nez.

Pour info, en 18 ans d'informatique personnel, j'ai connu des 8 bits (Amstrad CPC), des 16/32 bits (Amiga), puis des 32 bits (processeur 486 et suivant), et enfin, un 64 bits, avec mon Sempron 3100+.

Certe si problème il y a, il faut le déterminer et le corriger, mais de là à laisser entendre que F8 est instable et que c'est insupportable pour tout le monde, il y a un pas de géant...

Où ai-je dit cela ? Je demandais juste si quelqu'un avait des informations nouvelles sur ces problèmes de freeze aléatoires qui obligent à rétrograder la version du noyau, ce qui est quand même assez ennuyeux.

Paranoïa ?

Certe si problème il y a, il faut le déterminer et le corriger, mais de là à laisser entendre que F8 est instable et que c'est insupportable pour tout le monde, il y a un pas de géant...

F8 n'est pas instable, bien au contraire, il s'agit simplement du noyau -49 qui pose problème sur quelques configurations.

En effet. Cependant, avoir des freeze sur certaines configurations et être obligé de rétrograder le noyau, cela fait mal sur le plan "technique".

Peut-être que le -63 dans le dépot testing corrigera le tir ?

Peut-être que le -63 dans le dépot testing corrigera le tir ?

[admin@one rsync]$ uname -r
2.6.23.8-62.fc8
[admin@one rsync]$ uptime
 16:03:06 up 9 days, 20:38,  1 user,  load average: 0.70, 0.77, 0.84
[admin@one rsync]$

NB : C'est un -62 que j'ai actuellement et non un -63.

J'ai eu un freeze avec ce noyau. Depuis (presque 10 jours), plus de problème.
Le freeze est hypra aléatoire chez moi.

Pour info, je n'avais installer aucun pilote propriétaire quand j'ai eu droit aux freeze. Donc, le problème reste entier. Et j'aurais pourtant juré d'avoir lu -63 comme numéro de version 🙁

Et j'aurais pourtant juré d'avoir lu -63 comme numéro de version 🙁

Je vous en prie Thérèse, ne jurez pas 😉

Il y a un nouveau pilote béta (169.04) qui corrige pas mal de problèmes de stabilité, mais je ne sais pas si il est dispo chez livna/rpmfusion!

http://www.jeuxlinux.fr/

Mouais. Ce pilote à l'air intéressant, cependant :

"Résolution d'un bogue autour du noyau/chaîne d'outils Linux qui occasionnait des erreurs logicielles de lockup sur certains systèmes Intel "

Euh... Est-ce qu'un système basé sur de l'AMD64 peut être considéré comme de l'intel ? Sur ma ubuntu 7.10 AMD64 actuelle, je n'ai aucun problème avec les pilotes 100.14.19 pour ma vieillotte GeForceFX5200...

fredb1974 wrote:j'aurais pourtant juré d'avoir lu -63 comme numéro de version 🙁

Tu as bien lu. C'est moi qui ait un -62. En updates il y a le -63. Et je vais biensur passer au -63.

Question :
Es-ce quelqu'un a encore le problème de "freeze" avec le 2.6.23.8-63.fc8 ?
Je parle du problème où les accès disques tombent en rade puis le système se freeze après un "certain temps".
Je n'ai pas eu de problème depuis une douzaine de jours.

VINDICATORs wrote:Il y a un nouveau pilote béta (169.04) qui corrige pas mal de problèmes de stabilité, mais je ne sais pas si il est dispo chez livna/rpmfusion!

http://www.jeuxlinux.fr/

Effectivement, il l'est, pas encore pour le nouveau kernel F-7 mais il est disponible dans livna-testing...