F8 n'est pas instable, bien au contraire, il s'agit simplement du noyau -49 qui pose problème sur quelques configurations.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...
Freezes
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 ?
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.
- Modifié
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 🙁
Je vous en prie Thérèse, ne jurez pas 😉Et j'aurais pourtant juré d'avoir lu -63 comme numéro de version 🙁
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/
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...
"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...
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.fredb1974 wrote:j'aurais pourtant juré d'avoir lu -63 comme numéro de version 🙁
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.
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.
Effectivement, il l'est, pas encore pour le nouveau kernel F-7 mais il est disponible dans livna-testing...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/
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
- Modifié
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.
Ç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.
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 ...Marcet wrote:Je considère pour ma part que le problème est résolu.
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!
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.VINDICATORs wrote:Mais déjà le signaler c'est un grand pas!
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
Ça merde toujours. C'est un poil différent. J'ai envis de suspecter le timer. Je vais me compiler un noyau mais avec l'ancien timer. Quand j'aurais le temps 🙂web123 wrote:Sinon je vais essayer le 2.6.23.9-90