Reprise du message précédent :
Salut,
 
Depuis le début du confinement, je télétravail depuis ma machine Arch (sous kde/plasma), avec ces différents logiciels :
- openfortivpn
- Krdc
- Oracle SQL Developer
- Eclipse STS
- Code OSS (version open source de VSCode de M$)
- Filezilla (accès FTP / SFTP)
- Chromium et Firefox
 
La plupart du temps, aucun problème, sauf que de temps en temps (une fois par jour max), j'ai un blocage quasi total de mon interface graphique, qui bouge à genre 0,01fps ...
 
Je suis oblige de faire un hard reboot à chaque fois et je ne trouve rien dans les logs qui pourrait m'aiguiller vers le / les responsable(s).
 
Des idées ?
 
Merci d'avance

Pour commencer, configurer et utiliser les touches magiques : https://wiki.archlinux.fr/Sysrq
Ensuite, surveiller l'utilisation de ta mémoire (ram et swap) : ce que tu décris vient souvent de là.
Quand ton interface commence à se figer, fait Alt SysRq r (pour reprendre la main sur le clavier si besoin) puis Alt SysRq f : ça va tuer le process qui consomme le plus de ram.
Si ton ordi revient, c'est que c'était ça, sinon…  

C'est très rare de devoir redémarrer la machine matériellement, et aussi rarement une bonne idée.
 
Peux-tu t-y connecter par SSH quand elle bloque?
 
A tout hasard je dirais soit plus de RAM libre, soit un gros travail I/O.

La machine a 32go de ram, et je l'ai rarement vue monter à plus de 16 ... mais bon SQL developer est pas réputé pour bien gérer sa ram, donc possible qu'il s'emballe à un moment donné, je vais le surveiller.
 
Merci pour les Sysrq, je vais tenter la prochaine fois, et test de connexion via SSH aussi

T'as un ssd je suppose, pour le swap ?

Oui, le même ssd que pour /, /boot et /home

Ok, ben du coup c'est vrai que ce serait surprenant que le problème vienne de la ram / swap (ou même d'un gros travail I/O comme dit gee ?), mais bon…

J'ai eu un peu la même chose récemment aussi sur arch kde/plasma, l'interface figé 2-3 fois, en laissant le pc inactif un petit moment, mais je n'ai pas plus cherché que ça. J'ai mis ça sur le compte de la mise en veille, de la gestion de l'énergie, powertop ou un truc comme ça.
J'ai remarqué que l'autonomie avait augmenté, que la consommation descendait plus bas qu'avant (vers 7 W au lieu de 9-10). peut-être une gestion un peu trop agressive de l'énergie ...

 
Bon finalement je me suis décidé à éteindre le PC tous les soirs  

Je parlais du clavier pas du PC

C'est un branchement PS/2, je pense que ce n'est pas une bonne idée

@minux : tu utilises du nvidia comme carte graphique ?
Pilote propriétaire ou libre ?
Le problème existe depuis très longtemps ou n'est apparu que depuis un récent pacman -Syu ?

Si les gels d'écran disparaissent avec le pilote libre alors ça vient du pilote propriétaire nvidia.

Pour les bugs graphiques tu as le log de Xorg (/var/log/Xorg.0.log), mais celui de la session disparait dès un reboot.
Il y a aussi le log de journalctl : "journalctl -p err" à faire en root ou sudo.

Si pas de bugs du pilote graphique :

- Le bug peut venir de plasma, de Qt5, si c'est le cas alors tester avec un autre environnement de bureau (comme lxqt ou xfce) et un autre utilisateur.

- Le bug peut être dû à un logiciel qui a une fuite mémoire, une conso ram excessive, qui finit par saturer la mémoire, le swap disque va alors être utilisé, on voit la led du disque dur s'allumer pendant un long moment, tout le PC qui ralentit (curseur de souris qui bouge avec une forte latence), la commande pour vérifier la conso mémoire : "free -h".

- Un vieux bug linux non résolu : en cas de fortes (mais vraiment très fortes, genre une grosse copie d'un fichier de plusieurs dizaines de Go) opérations lecture/écriture du disque dur : le système peut devenir très lent, l'interface graphique quasi gelée, forte latence du curseur de souris, le clavier qui ne répond pas tout de suite, voire pas du tout, si tu attends quelques secondes ou minutes (le temps que la grosse opération I/O se termine) alors normalement le gel va disparaître, j'ai eu ce problème parfois lors de grosses copies de fichiers, c'est un peu aléatoire, pas facile à reproduire.

Quand l'interface est gelée : essaie d'ouvrir une console avec la combinaison de touches CTR-ALT-F2, puis tu consultes les journaux systèmes, les processus (commande "top" ou la commande "ps" ) pour savoir quel processus fait ramer le PC (possibilité de tuer le processus avec la commande kill), la consommation mémoire (free -m), la commande dmesg.

Si le PC a un serveur SSH : sur un autre PC en réseau on peut déboguer à distance via SSH, pour voir quel processus fait ramer le PC.

Teste enfin avec un autre noyau linux (un peu plus ancien, ou le noyau LTS).

Merci pour toutes ces infos, et oui c'est du Nvidia avec pilotes proprios, je vais regarder dans les logs lors du prochains freeze (je suis connecté en ssh sur ma machine depuis une autre pour surveiller)

moi aussi c'est nvidia avec les pilotes proprio.

En gros 5 scénarios possibles :

- pilote nvidia bogué avec la dernière version du noyau linux, xorg, wayland
- l'environnement de bureau plasma
- Qt5 sur lequel s'appuie plasma
- un logiciel qui a une fuite mémoire, qui prend trop de ressources au fur et à mesure que le temps s'écoule, au bout d'un moment il n'y a plus de mémoire disponible, le système va swapper comme un ouf d'où l'extrême lenteur
- un logiciel pris dans une boucle infinie, qui lance un calcul interminable qui met à genoux le CPU, le disque dur si opérations I/O importantes

Ouaip, un des 5, ça me paraît cohérent.

Par contre depuis mon msg de ce matin, aucun freezer, donc aucune avancée...

Tu peux retracer ce qu'il s'est passé avant il me semble en précisant le boot :
journalctl -p err -b3

Il suffit de changer le numéro du boot après -b

Dites à présent les paquets sont compressés avec zstd, on peut savoir quelle niveau de compression ils utilisent? J'ai bien vu la news dessus : https://www.archlinux.org/news/now- [...] mpression/ ainsi que le commit en question https://github.com/archlinux/archivetools/pull/7/files mais je ne vois pas s'ils utilisent la compression standard (niveau 3) ou si c'est un poil tuné.

J'ai modifié mon makepkg.conf pour utiliser cette compression sur les builds AUR, je passes de 52mo à 85mo de l'ancienne méthode (xz) à la nouvelle (zst) en compression standard et de 52 à 56mo en compression zst niveau 22 (le range est hors du man mais d'après la doc et les issues github de zst ça fonctionne encore). A compression 22, je ne vois de réel gain (temps de compression notamment)  ... De 3 jusqu'à 8 c'est évident mais le poids de l'archive gonfle.

Voici la ligne issue de mon makepkg que j'utilise :
COMPRESSZST=(zstd -c -T8 -z -12 -q -) #Compression level 12

A noter d'ailleurs que le -T0 ne fonctionne pas bien puisqu'il utilise la moitié des threads disponibles et non pas tous. Il doit détecter les cœurs physiques et non pas les threads. Je reste un peu dubitatif devant l'usage de cette lib facebook ...

Perso pour mes propres paquets je ne compresse pas vu que mon FS utilise déjà zstd, ca serait de la perte de temps...

Sur plusieurs machines je préfère compresser pour les transferts réseaux. En niveau 3 zstd, la compression est express ceci étant !

Good, avec ça je pense avoir trouvé le responsable : Teams, version 1.3.00.5153-1, installée depuis AUR (outil obligatoire dans ma boite pour toutes les réunions et appels pros), y'a des tonnes de lignes en rouge dans la sortie ...
 
Merci pour l'aide, je vais essayer de trouver un moyen de me passer de ça

Attention aux dates avec l'option -b de journalctl : -b3 va t'afficher le troisième boot archivé dans l'ordre chronologique : ça doit dater.
Si tu veux l'affichage du dernier boot (avant le boot courant) : journalctl -b-1
 
Rq : à exécuter en root ou avec sudo, pour avoir tous les messages.

Tu peux aussi préciser directement la date et l'heure dans les options de journalctl, comme ça t'es sûr d'avoir le bon log.
 

Si tu sais d'où vient le soucis tu peux toujours passer le timeout de systemd sur ce service a 5 secondes ou meme moins. D'ailleurs, as tu vraiment besoin d'un service pour? (Je ne sais pas ce qu'est donc peut-être).

J'en ai besoin pour aujourd'hui de teams, je viens juste de l'installer .... Je te dirais si ça freeze.
Du coup on comprend mieux le rachat de nodejs de la part de Microsoft. Je ne connaissais pas code oss, ça fait réfléchir sur son usage ...
 
 
Pour lister les boot sinon :
journalctl --list-boots

 
Merci pour toutes ces précisions.
 

 
Oui je vais diminuer le timeout, bonne idée, et je pense que Teams à besoin d'un service pour tourner en arrière plan, mais vu que je sais pas comment il fonctionne (et pour faire rapide c'est le nouveau Skype de Microsoft qui va à terme le remplacer)

Cette fois-ci, c’est un problème de son sur mon PC portable (HP Pavilion dv6 1140ef), apparu après le redémarrage consécutif aux dernières mises à jour…

Je vais vous faire un comparatif rapide avant/après :

• Jusqu’à ce mardi matin, je réglais le son des enceintes intégrées à 50% sur le mixeur de PulseAudio. Si j’avais réglé un niveau différent, ou mis en muet, quand je branche mon casque sur la prise jack, ça basculait automatiquement sur le niveau sonore défini pour le casque (et réciproquement). De plus, cet ordinateur a une rangée de touches multimédias tactiles (des LED blanches) : appuyer sur celle permettant de couper ou remettre le son faisait passer la LED concernée en orange ou en blanc.
• Je ne m’en suis rendu compte qu’en soirée, mais maintenant, le son est devenu beaucoup plus faible à % égal (je dois mettre le son général à au moins 80% pour retrouver le niveau d’avant, et encore, peut-être plutôt 90%). Brancher ou enlever le casque ne change plus le réglage automatiquement, et couper/remettre le son depuis le bouton tactile ne change plus la couleur de l’icône (mais le son est bien coupé/rétabli).

Voici la liste des MAJ faites ce mardi :

A priori, je vois que le passage au noyau 5.6 qui pourrait être la cause de ce changement. Je vois mal de simples mises à jour des gst-plugins-* être la cause de tout ça.

Ah, pour les références de la carte audio, vue par INXI :

J’essaierai de démarrer sur le noyau LTS pour voir si c’est la même chose.

Tu peux aussi downgrader le noyau linux vers la version précédente 5.5.13, pour voir si le bug disparaît, via la commande "pacman -U <le chemin vers le fichier zst>".
Les paquets version "n - 1" sont situés dans le chemin /var/cache/pacman/pkg

Autre solution : ouvrir une session avec un utilisateur de test, afin de voir si avec un home vierge le problème disparaît, ça pourrait alors venir d'un fichier de configuration incorrect lié au son (pulseaudio, alsa) présent dans le home de ton compte utilisateur habituel.

Je suis en train d'expérimenter un bug de lenteur de déplacement de fichiers :
 
-  j'ai voulu déplacer (avec Dolphin de kde) un gros dossier de 16 Go (d'un disque dur interne) composé de plein de petits fichiers (274 027), vers un second disque dur interne,  
au début la copie se passe bien, débit d'écriture rapide du disque, pas de lenteur de l'interface graphique, puis vers la fin le débit ralentit sévèrement, il n' y a plus que 2 Go de données à écrire mais ce n'est toujours pas fini depuis une heure,
le débit fait penser à une copie entre 2 périphériques lents, alors que ce sont des disques dur sata, peut-être est-ce la fragmentation sur le disque dur et le fait que ce soit des petits fichiers (partitions ext4), ou bien un bug de Dolphin pour la copie et le déplacement de fichiers.
 
Pas de ralentissement de l'interface graphique, mais le système est un poil plus lent.
 
edit :  
https://bugs.kde.org/show_bug.cgi?id=282500
https://bbs.archlinux.org/viewtopic.php?id=192828

 
C'est la première chose que tu devrais essayer  

 
C'est un phénomène que je constate depuis des années cette lenteur générale du système dès qu'on lance une grosse copie d'un disque à l'autre. C'est super pénible. Windows n'a pas ce problème...

N'est-ce pas lié au fait que ce soit synchrone et non asynchrone?
Mais oui j'ai déjà vu ce phénomène et cela même sur un SSD NVMe.

J’allais pas redémarrer exprès à ce moment-là…
 
Alors, j’ai essayé avec le noyau LTS, et devinez quoi ? Oui, oui : la gestion du son redevient OK. J’ai même accès aux contrôles de la carte « HDA Intel » dans Alsamixer (avec le 5.6.2, le logiciel est quitté brutalement avec ce message : « les commandes de mixage ne peuvent pas être chargés: Argument invalide »).
 
Je pense que là, on peut clairement dire qu’il y a un bout de code qui ne va plus depuis la passage à la branche 5.6…
 
Sinon, aujourd’hui, ça fait 5 ans que j’ai installé Arch pour la première fois en dur, et accessoirement sur cet ordinateur.
 
EDIT : les seules différences que je vois dans les fichiers du paquet linux chez Arch en 5.6.0 sont ces lignes :
 

(passé à « +# CONFIG_SND_CTL_VALIDATION is not set » dans le prochain noyau 5.6.3 ; je sais pas si ça va changer quelque chose), et
 

(mais je sais pas si, là aussi, ça a un impact)
 
Re-EDIT : ah; j’ai trouvé ça dans les rapports de bugs :
https://bugs.archlinux.org/task/66148, qui mène à celui-ci, sur le bugtracker du noyau lui-même :
https://bugzilla.kernel.org/show_bug.cgi?id=207139
Alors, moi, j’ai du son, mais ça ressemble à mon souci. Avec de la chance, mon bug sera corrigé avec ce changement de paramètre CONFIG_SND_CTL_VALIDATION…

Pour le ralentissement lors de la copie de fichiers via un gestionnaire de fichiers, pareil, j'ai déjà vu ça plein de fois, et encore récemment sous xfce / thunar (pas au point que décrit Elbarto ceci dit, mais c'était des films que je copiais, pas des petits fichiers).
Ça me fait penser à ce que je disais récemment sur le fil xfce : j'ai jamais vu un gestionnaire de fichiers qui soit pas bugué…
Bref, pour ça comme pour tant d'autres choses, une solution simple existe : passer en ligne de commande (à moins que le problème persiste dans ce cas, mais ça, je l'ai pas souvent constaté par contre)

Pas bête faudra que j'essaye  

J'avais pas rebooté hier, après màj du noyau (je suis toujours en décalage d'un jour dans ces cas-là).
Aujourd'hui : plus de son    
Problème décrit par Trit' je suppose…
Du coup, passage en noyau lts (comme quoi, il faut toujours l'avoir sous le coude).

Il y a 2 patchs disponibles sur le rapport de bug posté plus haut, ils semblent résoudre le bug.

Perso j'attendrai un correctif par les màj, en restant tranquillement en lts en attendant : j'ai d'autres patchs à tester sur d'autres trucs pour le moment, pas envie de me lancer là-dedans    

Les patchs sont normalement intégrés à la nouvelle version 5.6.3, d’après ceux qui l’ont installée. Elle était en testing, ce matin.

Un bug a du être corrigé je ne sais ou, mais depuis mon message de demande d'aide, je n'ai eu aucun problème

Comme prévu : l’installation du noyau 5.6.3 corrige mon problème de gestion du son (et certainement ceux des autres qui en avaient ici) sur mon portable. Tout refonctionne impeccablement.

Je teste la copie en ligne de commande d'un gros dossier de 34 Go depuis le disque dur interne vers un disque dur externe , le PC ne rame plus du tout pendant la copie, merci