BERTRAND Joël a écrit : > Bonjour, > > Y a-t-il un problème sur la liste ? J'ai envoyé deux messages qui > n'apparaissent pas alors que j'en ai reçu plusieurs autres plus récents... >
Comme celui-ci est passé, je reposte mes message. Désolé si les deux premiers passeront en double... Copie du message de ce matin : Bonjour à tous, J'avoue que le problème me dépasse et n'est visiblement pas restreint aux vidéos. Je pense même que les erreurs NFS proviennent de la même cause. J'ai actuellement deux machines en Debian/testing. Elles sont diskless toutes les deux et tournent toutes les deux en testing à jour. hilbert: - cpu : Intel(R) Core(TM) i9-10900F CPU @ 2.80GHz - carte graphique : VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) - fstab : 192.168.10.128:/srv/hilbert / nfs tcp,nfsvers=3,async 0 0 192.168.10.128:/home /home nfs tcp,nfsvers=3,async,nolock 0 0 192.168.10.128:/opt/video /opt/video nfs tcp,nfsvers=3,async,nolock 0 0 heisenberg: - cpu : Intel(R) Core(TM) i5-4570 @ 2.90GHz - GPU intel - fstab 192.168.10.128:/srv/heisenberg / nfs intr,tcp,nfsvers=3,async 0 0 192.168.10.128:/home /home nfs intr,tcp,nfsvers=3,async 0 0 192.168.10.128:/opt/video /opt/video nfs intr,tcp,nfsvers=3,async 0 0 Hilbert fonctionne normalement (aucune erreur). Je constate qu'il y a une option intr qui traîne, mais celle-ci est ignorée si j'en crois la page man (ce qui prouve que l'OS a été installé avant le noyau 2.6.25...). Je vais retirer cette option. De la même façon, j'ai un nolock sur /home et /opt/video sur hilbert que je n'ai pas sur heisenberg. Cependant, avec le noyau 4.19, tout se passait correctement et si je vois bien le rapport entre les options NFS et les erreurs dans la console, je ne vois pas trop le rapport avec les timers. Il faut cependant noter qu'avec le noyau 4.19, tout se passait correctement (aucune erreur NFS, aucun problème pour lire des vidéos). J'ai bien essayé de redémarrer un 4.19, mais ce <censure> de systemd est tellement imbriqué avec le noyau qu'il refuse de fonctionner normalement et le démarrage d'un 4.19 échoue ! Je ne suis toutefois pas convaincu que le fait de retirer l'option nolock va résoudre le problème puisque /var/log/syslog montre que les erreurs NFS proviennent de / et non de /home (les erreurs sont tracées avant que /home ne soit montée). Je n' ai rien vu de particulier dans le dmesg de heisenberg. Le serveur NFS est un serveur NetBSD 9.2 (i7-4770, 16 Go, treize disques en grappes Raid1, Raid5, Raid6 et Ccd pour les swaps), largement dimensionné et le daemon NFS fonctionne avec 16 threads. J'ai essayé d'augmenter le nombre de threads, mais cela dégrade les performances (il vaut mieux qu'un client se prenne une erreur NFS de temps en temps plutôt que de faire monter la charge du serveur, j'ai fait des benchmarks sur le sujet). NFS est en V3/TCP (j'avais essayé UDP, mais ça n'améliore pas les choses et ça peut poser des problèmes sporadiques). Typiquement, la charge du serveur est inférieure à 1 et il répond sans problème. En retirant l'option intr et en rajoutant nolock sur /home et /opt/video, j'arrive à ouvrir KDE sans que cela ne plante. Mais il y a toujours des problèmes de vidéo. De temps en temps, ça fonctionne, puis ça se met à ne plus fonctionner. J'ai essayé à partir d'un compte avec un VLC correctement paramétré et le résultat est le même que le décodage soit fait par VAAPI ou en soft (libplacebo). Au bout d'un certain temps, la sortie son fini par devenir inactive et il me faut redémarrer la machine pour qu'elle fonctionne à nouveau. Je prends toute idée... Bien cordialement, JKB