@fredb1974
Est ce bien utilile ce service de lien ? Préfères lier à la doc du site...
J'avais fait une recherche sur bugzilla et ce matin, il n'y avait que 4 bugs avec le mot clé freeze, je vois que la liste s'allonge. Mais à priori aucun ne décrit directement notre problème (qui semble avoir disparu pour moi en revenant à la version 2.6.23.1-42).
Je confirme que je ne freeze plus avec la version 42 du kernel.
johnny_joe58 wrote:Il n'y a que deux fois où j'ai réussi à tuer le serveur X (avec Ctrl-Alt-Backspace) avant que tout ne freeze, et dans ce cas
gdm a redémarré X
Je l'ai fait aussi et comme toi gdm a redémarré X sans problème.
J'ai une vieille carte graphique : Maxtor G400

Une personne qui avait un problème semblable a installer le driver (xorg-x11-drv-ati) de F7 et ça semble marcher pour lui.
C'était une carte ati.

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

Pour installer, faire un truc dans ce gout :
rpm -Uvh --oldpackage http://fr2.rpmfind.net/linux/fedora/releases/7/Everything/i386/os/Fedora/xorg-x11-drv-mga-1.4.6.1-3.fc7.i386.rpm
je vous recommande avant tout et surtout en 64 bits le test memoire
lors du demarrage du DVD d'installation de fedora 8.
vous serez quelque peu surpris sur les 8 tests.
j'ai eu des problèmes de freeze sur le pc du fiston (carte LAN Party DF4) carte mal overclocked.
et ça ne prends 1/2 heure de test sur 2 Go de ram DDR
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...
10 jours plus tard
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 ?
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