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

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!

web123 wrote:Sinon je vais essayer le 2.6.23.9-90

Ç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:Je vais me compiler un noyau mais avec l'ancien timer. Quand j'aurais le temps 🙂

Voilà qui est fait (même source que F8). Je me suis fait un noyau qu'avec le nécessaire (mais pas de perte de fonctionnalité pour ce que je fais).

J'ai un peu galéré, donc voici quelques infos :
* F8 utilise libpata. Donc même pour les disque IDE ça passe par SCSI. Il faut donc compiler SCSI.

* Et voilà le point où j'ai le plus galéré. Hal/ConsoleKit utilise ACL. Il faut donc compiler tmpfs avec ACL (sinon il n'y a pas de son).

Espérons que ça ne freeze plus. Si c'est le cas, je ferais un rapport de bug si le problème persiste avec le prochain 2.6.24 de F8.

web123 wrote:

web123 wrote:Je vais me compiler un noyau mais avec l'ancien timer. Quand j'aurais le temps 🙂

Voilà qui est fait (même source que F8). Je me suis fait un noyau qu'avec le nécessaire (mais pas de perte de fonctionnalité pour ce que je fais).

J'ai un peu galéré, donc voici quelques infos :
* F8 utilise libpata. Donc même pour les disque IDE ça passe par SCSI. Il faut donc compiler SCSI.

* Et voilà le point où j'ai le plus galéré. Hal/ConsoleKit utilise ACL. Il faut donc compiler tmpfs avec ACL (sinon il n'y a pas de son).

Espérons que ça ne freeze plus. Si c'est le cas, je ferais un rapport de bug si le problème persiste avec le prochain 2.6.24 de F8.

Le problème c'est que si tu fais un rapport de bug en disant que cela fonctionne mal avec une option et qu'il faut revenir à une option plus "standard", je suis pas sur que l'on prête beaucoup d'attention à ton bug... Fedora est une distribution qui se veux portée sur l'évolution... Donc si certaines fonctionnalités manque de stabilité, il vaut trouver le moyen de savoir pourquoi (rester sur un kernel Fedora), voire prendre un kernel qui reste fonctionnel...

kwizart wrote:Le problème c'est que si tu fais un rapport de bug en disant que cela fonctionne mal avec une option et qu'il faut revenir à une option plus "standard", je suis pas sur que l'on prête beaucoup d'attention à ton bug... Fedora est une distribution qui se veux portée sur l'évolution... Donc si certaines fonctionnalités manque de stabilité, il vaut trouver le moyen de savoir pourquoi (rester sur un kernel Fedora), voire prendre un kernel qui reste fonctionnel...

Tu as tout à fait raison. La suppression d'une fonctionnalité n'est pas la solution. C'est uniquement temporairement un contournement et pour arriver à cerner d'où vient le problème. Si je peux dire que c'est telle ou telle fonctionnalité du noyau qui "sucks", les développeurs seront où travailler. Ce sera un bon pas en avant.

J'ai changé de PC (un joli cadeau de noël).
Je suis en train de tout migrer vers ce nouveau PC. C'est beaucoup beaucoup de boulot, mais ça se fait sans soucis sérieux.
Je passe aussi sous x86_64. Merveilleux de voir comme Fedora supporte cette architecture les doigts dans le nez.

Pour information : depuis que j'ai recompilé le noyau (voir les messages précédents), je n'ai pas eu de freeze (en une quinzaine de jours).

Merci à ceux qui ont prêté leur attention. Bon courage pour ceux qui ont encore des problèmes.

M'enfin, il n'est pas encore garanti que je n'ai pas de freeze avec le nouveau PC 🙂

J'adore l'esprit Fedora 🙂