- Modifié
Dans le lien que tu cites, il y a la façon de recompiler un noyau fedora (chapitre 7 et suivants), tu n'auras juste qu'à ajouter ton patch dans /rpmbuild/SOURCES et ajouter cette entrée dans /rpmbuild/SPECS/kernel.spec
[Résolu] X.org et noyau temps réel
Salut à tous !
Merci de ta réponse Chepioq.
Cela dit, je me rends compte que je fais en fait fausse route.
Que ce soit avec le noyau temps réel ou le noyau classique, j’ai des gels réguliers du serveur X. Simplement, sous le noyau classique je peux reprendre la main après un court instant, alors qu’avec le noyau temps réel je ne peux jamais reprendre la main. Cependant, en me connectant par SSH, l’ordinateur est toujours réactif.
Donc, le problème, c’est le serveur X, pas le noyau. Du coup, je pense que ça ne sert à rien de s’acharner sur le noyau, alors que c’est le serveur X qu’il faut corriger.
Donc, première chose, réaliser un diagnostic pour déterminer ce qui ne va pas. Justement, à ce niveau, je ne vois pas trop quoi faire. Le journal ne semble pas donner grand-chose :
À bientôt.
Le Farfadet Spatial
Merci de ta réponse Chepioq.
Cela dit, je me rends compte que je fais en fait fausse route.
Que ce soit avec le noyau temps réel ou le noyau classique, j’ai des gels réguliers du serveur X. Simplement, sous le noyau classique je peux reprendre la main après un court instant, alors qu’avec le noyau temps réel je ne peux jamais reprendre la main. Cependant, en me connectant par SSH, l’ordinateur est toujours réactif.
Donc, le problème, c’est le serveur X, pas le noyau. Du coup, je pense que ça ne sert à rien de s’acharner sur le noyau, alors que c’est le serveur X qu’il faut corriger.
Donc, première chose, réaliser un diagnostic pour déterminer ce qui ne va pas. Justement, à ce niveau, je ne vois pas trop quoi faire. Le journal ne semble pas donner grand-chose :
$ tail /var/log/Xorg.0.log
[181012.025] (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e)
[181012.025] (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
[181012.025] (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e)
[181012.025] (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[181012.025] (II) RADEON(0): Modeline "1280x800"x0.0 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz e)
[181012.025] (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e)
[181012.025] (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[181012.025] (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz e)
[181012.025] (II) RADEON(0): Modeline "1680x1050"x0.0 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[181012.025] (II) RADEON(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
$ dmesg | grep ATI
[ 4.758255] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1c.4/0000:04:00.1/sound/card1/input5
$ dmesg | grep radeon
[ 3.214088] [drm] radeon kernel modesetting enabled.
[ 3.214479] radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 3.214481] radeon 0000:04:00.0: GTT: 1024M 0x0000000020000000 - 0x000000005FFFFFFF
[ 3.214536] [drm] radeon: 512M of VRAM memory ready
[ 3.214537] [drm] radeon: 1024M of GTT memory ready.
[ 3.250224] [drm] radeon: dpm initialized
[ 3.276134] radeon 0000:04:00.0: WB enabled
[ 3.276138] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff88003660dc00
[ 3.276140] radeon 0000:04:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff88003660dc0c
[ 3.288021] radeon 0000:04:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc9000481c418
[ 3.288055] radeon 0000:04:00.0: irq 51 for MSI/MSI-X
[ 3.288086] radeon 0000:04:00.0: radeon: using MSI.
[ 3.288117] [drm] radeon: irq initialized.
[ 3.778910] fbcon: radeondrmfb (fb0) is primary device
[ 3.894161] radeon 0000:04:00.0: fb0: radeondrmfb frame buffer device
[ 3.894161] radeon 0000:04:00.0: registered panic notifier
[ 3.894246] [drm] Initialized radeon 2.38.0 20080528 for 0000:04:00.0 on minor 0
$ dmesg | grep VGA
[ 0.000000] Console: colour VGA+ 80x25
[ 3.644890] [drm] VGA-1
[ 4.746207] snd_hda_intel 0000:04:00.1: Handle VGA-switcheroo audio client
$ dmesg | grep video
[ 0.240365] pci 0000:04:00.0: Boot video device
[ 4.757930] Linux video capture interface: v2.00
[ 4.810993] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
[ 4.831239] usbcore: registered new interface driver uvcvideo
À bientôt.
Le Farfadet Spatial
Moi j'aimerais bien voir un fichier complet Xorg.0.log après plantage.
Lorsque ça se produit, redémarre en niveau 3 et recopie le dernier fichier Xorg.0.log ailleurs.
Puis poste-le ici.
Lorsque ça se produit, redémarre en niveau 3 et recopie le dernier fichier Xorg.0.log ailleurs.
Puis poste-le ici.
Salut à tous !
J’ai lancé une vidéo (c’est dans ces cas là que le gel arrive le plus vite) et j’ai attendu que X fige. Ensuite, j’ai commencé à rédiger ce message, mais au bout de plus d’une minute, X est reparti là où il en était. En fait, X fige toute les deux à trois minutes et se débloque après un peu plus d’une minute. Contrairement à ce que je pensais, il ne s’agit pas d’un crash, mais d’un gel. En fait, les même gels que j’expérimente avec le noyau classique, sauf qu’avec le noyau classique ça dure moins d’une seconde et avec le noyau temps réel ça dure plus d’une minute.
Voici quelques éléments suite à l’un de ces gels :
À bientôt.
Le Farfadet Spatial
Comme déjà indiqué, lorsque X fige, le noyau reste réactif. Du coup, plutôt que de relancer la machine, je comptais récupérer le tout par SSH.nouvo09 wrote: Moi j'aimerais bien voir un fichier complet Xorg.0.log après plantage.
Lorsque ça se produit, redémarre en niveau 3 et recopie le dernier fichier Xorg.0.log ailleurs.
J’ai lancé une vidéo (c’est dans ces cas là que le gel arrive le plus vite) et j’ai attendu que X fige. Ensuite, j’ai commencé à rédiger ce message, mais au bout de plus d’une minute, X est reparti là où il en était. En fait, X fige toute les deux à trois minutes et se débloque après un peu plus d’une minute. Contrairement à ce que je pensais, il ne s’agit pas d’un crash, mais d’un gel. En fait, les même gels que j’expérimente avec le noyau classique, sauf qu’avec le noyau classique ça dure moins d’une seconde et avec le noyau temps réel ça dure plus d’une minute.
Voici quelques éléments suite à l’un de ces gels :
$ uname -a
Linux petra 3.12.12-300.rt19.1.fc20.ccrma.x86_64+rt #1 SMP PREEMPT RT Mon Feb 24 17:07:56 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg | grep radeon
[ 3.268892] [drm] radeon kernel modesetting enabled.
[ 3.270300] radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 3.270302] radeon 0000:04:00.0: GTT: 1024M 0x0000000020000000 - 0x000000005FFFFFFF
[ 3.270868] [drm] radeon: 512M of VRAM memory ready
[ 3.270871] [drm] radeon: 1024M of GTT memory ready.
[ 3.297869] radeon 0000:04:00.0: WB enabled
[ 3.297873] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801130bbc00
[ 3.297874] radeon 0000:04:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff8801130bbc0c
[ 3.309694] radeon 0000:04:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc9000541c418
[ 3.309726] radeon 0000:04:00.0: irq 51 for MSI/MSI-X
[ 3.309924] radeon 0000:04:00.0: radeon: using MSI.
[ 3.310447] [drm] radeon: irq initialized.
[ 3.667563] [drm] radeon: power management initialized
[ 3.781577] fbcon: radeondrmfb (fb0) is primary device
[ 4.092568] radeon 0000:04:00.0: fb0: radeondrmfb frame buffer device
[ 4.092569] radeon 0000:04:00.0: registered panic notifier
[ 4.092572] [drm] Initialized radeon 2.34.0 20080528 for 0000:04:00.0 on minor 0
$ dmesg | grep VGA
[ 0.000000] Console: colour VGA+ 80x25
[ 3.667480] [drm] VGA-1
[ 5.311281] ALSA sound/pci/hda/hda_intel.c:3170 0000:04:00.1: Handle VGA-switcheroo audio client
$ dmesg | grep video
[ 0.259464] pci 0000:04:00.0: Boot video device
[ 5.325943] Linux video capture interface: v2.00
[ 5.360811] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
[ 5.377326] usbcore: registered new interface driver uvcvideo
À bientôt.
Le Farfadet Spatial
Le fait que le gel dure plus longtemps avec un noyau rt est normal, j'ai lu ça quelque part, il faudrait que je retrouve la page (si mes souvenir sont bons, c’était sur le forum américain de fedora).
En définitive, c'est sur fedora-fr que j'ai trouvé noyau-temps-réel : http://doc.fedora-fr.org/wiki/Fedora_et_le_Temps_R%C3%A9el chapitre 5 : Linux et le Temps Réel dur
Salut à tous !
Ce qui n’est pas normal, c’est le fait que j’ai couramment ces gels, quel que soit le noyau. Ce qu’il faut, c’est comprendre la raison de ces gels et la corriger.
Je continue les investigations.
À bientôt.
Le Farfadet Spatial
Tout à fait : lorsque j’ai enfin réalisé qu’il s’agissait d’un gel et non pas d’un crash, je me suis immédiatement dit que c’était parfaitement normal qu’il dure plus longtemps avec le noyau temps réel.chepioq wrote: Le fait que le gel dure plus longtemps avec un noyau rt est normal
Ce qui n’est pas normal, c’est le fait que j’ai couramment ces gels, quel que soit le noyau. Ce qu’il faut, c’est comprendre la raison de ces gels et la corriger.
Je continue les investigations.
À bientôt.
Le Farfadet Spatial
un mois plus tard
Salut à tous !
Oui, j’ai encore laissé ce sujet pendant un certain temps. La raison en est que je voulais m’assurer que j’avais bien réussi à résoudre le problème.
Donc, oui, je l’ai résolu.
En fait, il s’avère que la carte-mère était défectueuse, ceci depuis pas mal de temps (plusieurs années). Elle a fini par rendre définitivement l’âme… Avec la nouvelle carte-mère, aucun problème, je peux faire tourner le noyau temps réel (mais aussi le noyau classique) sans gel intempestif.
Donc, problème résolu.
À bientôt.
Le Farfadet Spatial
Oui, j’ai encore laissé ce sujet pendant un certain temps. La raison en est que je voulais m’assurer que j’avais bien réussi à résoudre le problème.
Donc, oui, je l’ai résolu.
En fait, il s’avère que la carte-mère était défectueuse, ceci depuis pas mal de temps (plusieurs années). Elle a fini par rendre définitivement l’âme… Avec la nouvelle carte-mère, aucun problème, je peux faire tourner le noyau temps réel (mais aussi le noyau classique) sans gel intempestif.
Donc, problème résolu.
À bientôt.
Le Farfadet Spatial
- Modifié
Ok, j'ai eu le même soucis avec mon amd X2 64 4600+ et mon ancienne carte mère, mais bon je soupçonne plus le cpu vu que j'avais le même souci avec une autre carte. Je ne me suis pas fait chier, j'ai carrément tout changé dès que j'ai pu. Sans compter qu'il planté aléatoirement dès qu'il était à la vitesse normal... Mais bon après on a pas toujours les finances pour remplacé, du coup on fait avec...
J'en ai déjà parlé, mais c'est vrai que l'on n'y pense pas et que souvent on a pas vraiment moyen de savoir le pourquoi du comment sur pas mal de modèle, car si ça ne bipp, voir ne retourne pas d'erreur,pas bonjour pour le détecter. Sur la nouvelle elle est plus armée à ce sujet 🙂.
Pour exemple : j'avais un disque dur qui semblait sain et pourtant il se bloqué sans raison. Pour au final s'apercevoir que c'était le moteur qui était HS, mais il ne faisait pas d'erreur ni rien... Mais ramé par moment. Mes oreilles arrivent à les détecter, mais il faut arriver à le faire comprendre au SAV et ce n'est pas souvent simple...
J'en ai déjà parlé, mais c'est vrai que l'on n'y pense pas et que souvent on a pas vraiment moyen de savoir le pourquoi du comment sur pas mal de modèle, car si ça ne bipp, voir ne retourne pas d'erreur,pas bonjour pour le détecter. Sur la nouvelle elle est plus armée à ce sujet 🙂.
Pour exemple : j'avais un disque dur qui semblait sain et pourtant il se bloqué sans raison. Pour au final s'apercevoir que c'était le moteur qui était HS, mais il ne faisait pas d'erreur ni rien... Mais ramé par moment. Mes oreilles arrivent à les détecter, mais il faut arriver à le faire comprendre au SAV et ce n'est pas souvent simple...