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 ?
solution: diminue resolution
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.
personnellement pour retrouver la stabilite avec des noyaux recents et des cartes nvidia serie 7 g du utiliser les pilotes serie 96xx (normalement pour geforce 4) sur plusieurs machines principalement athlon x2 la simple presence des series 100 provoquait des frezze
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...
J'ai pas encore eu l'occasion de tester le -63, mais je l'installe dès demain et je vous tiens au courant.
Ca a l'air plus stable sur fixe 64bits, il faudrait que l'update passe sur mon laptop aussi car c'est lui qui plante le plus :-X
Et merde, je viens d'avoir un "freeze".
Ça fait un tous les 15 jours. C'est supportable même si ça reste anormal.

Édit : avec le 2.6.23.8-63.fc8.
C'est effectivement beaucoup plus stable avec les dernières mises à jour.
Je considère pour ma part que le problème est résolu.
Marcet wrote:Je considère pour ma part que le problème est résolu.
Je ne partage pas ton avis. M'enfin, si tu n'as pas de soucis ...
Hors de question ici de critiquer les développeurs qui nous ont fait tant de bijoux. Mais un bug est un bug.
Je ne veux pas déranger de façon "précipité" les développeurs pour un bug si aléatoire et d'autant plus que j'ai quasi aucune information à fournir.
Je regarderai de prêt le 2.6.24 et ferai un rapport de bug si mon problème persiste.
C'est cela le travail communautaire! si en plus tu trouve et corrige le bogue c'est encore mieux!

Mais déjà le signaler c'est un grand pas!
VINDICATORs wrote:Mais déjà le signaler c'est un grand pas!
Je ne veux pas te contredire. Si quelqu'un fait un rapport de bug à ma place, j'ai rien à lui reprocher.
Ce qui me soucie, c'est que j'ai rien comme info !
J'ai déjà fait des rapports de bug (autour d'une vingtaine qui ont tous été corrigés) et j'avais toujours des infos à fournir et parfois le patch qui corrige le problème.
Si tu n'as aucun information à fournir, ça fait du buzz, et en gros c'est de la perte de temps pour les développeur pour rien. Étant moi même un développeur, je comprend très bien ce type de situation.

Sinon je vais essayer le 2.6.23.9-90 :
http://koji.fedoraproject.org/koji/buildinfo?buildID=27830
Ce qui a retenu mon attention :
- highres-timers: fix possible hang