Discussion :

[Jipété]

Bonjour,

(je ne sais pas du tout à quel sous-forum attribuer ce post)

Expérience vécue à l'instant : je crée un nouveau sous-dossier dans un dossier qui en contient déjà des tas, j'ai 3 pdf/png à y archiver, en attente sur le Bureau.

Donc une fois ce sous-dossier créé, je le réduis et clique avec Ctrl appuyé pour sélectionner les 3 fichiers que je veux y déposer, donc clic-droit / couper pour faire ensuite dans le sous-dossier concerné un clic-droit / coller mais non !
Plus rien ne fonctionne !
N'importe où que je clique il ne se passe plus rien...

Et à force de vivre ce genre de merdasse depuis 2 ou 3 ans, je sais maintenant ce qu'il faut faire : appui long sur le bouton PowerOn pour éteindre violemment la machine, attendre quelques secondes pour la rallumer et tout refonctionne. Jusqu'à la prochaine fois...

Mais ça fait des années que j'ai ce phénomène, totalement aléatoire et franchement désagréable, d'autant plus que je ne l'ai jamais vécu pendant les 20 années qui précèdent.
Ce comportement lamentable est nouveau, probablement depuis la mise en prod totale de systemD.

Linux Debian 12.12 à jour.
Et je n'attends pas de réponse, àmha, il n'y en a pas.

PS : j'ai cliqué sur Abonnement Instantanée, par email, comm' d'hab', et si j'en parle c'est parce que j'ai constaté avant-hier qu'un post me concernant ne m'a pas prévenu de sa présence... KC, le système d'alerte ? On va bien voir : ça serait cool que quelqu'un réponde, juste pour dire "bonjour" et tester les alertes.

[Artemus24]

Salut Jipété.

Bonne année 2026, bonne santé, mes meilleurs vœux à tes proches et à toi-même.

Je ne rencontre pas le problème du copier/coller que tu indiques sous Debian Trixie.
Un petit problème peut en cacher un plus gros. As tu eu un problème ces derniers temps ?
Je ne sais pas mais du genre coupure de courant durant une cession ou un virus ...
As tu le même genre de problème avec les versions antérieures ?
Faudrait peut-être envisager de réinstaller ton OS.

Es tu dans une machine virtuel ou comme moi dans mon ordinateur portable ?
Pourrais tu détailler ton environnement ?

[disedorgue]

juste après le problème et le reboot, peut-être une commande du même genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

journalctl  --since "10 min ago"

pourrait donner une piste...

[CosmoKnacki]

Ce que tu décris là me fait penser à des pannes aléatoires d'un disque dur en fin de vie.

[Jipété]

As-tu eu un problème ces derniers temps ?

À part celui que j'ai décrit, la réponse est "non".

As-tu le même genre de problème avec les versions antérieures ?

Non.

Faudrait peut-être envisager de réinstaller ton OS.

Je ne suis pas fan de ce genre de manip.

Es-tu dans une machine virtuelle ou comme moi dans mon ordinateur portable ?

Ordinateur fixe dans un environnement propre.

Pourrais tu détailler ton environnement ?

Une bête machine d'assembleur (carte-mère GigaByte) avec 1 SSD et 2 HDD (l'un pour sauvegarder l'autre).
Mais ne me demandez pas la quantité de mémoire ni sa qualité, je n'en sais rien, c'est le genre de chose que j'oublie, une fois la machine achetée et installée.

juste après le problème et le reboot, peut-être une commande du même genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

journalctl  --since "10 min ago"

pourrait donner une piste...

Je note dans un coin ta manip, merci, mais comme je viens de l'utiliser (pour voir ce que ça donne -- je ne la connaissais pas), j'y ai découvert une ligne amusante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

janv. 09 08:02:00 debox64 pulseaudio[1138]: After module unload, module 'module-null-sink' was still loaded!

Si le système n'est pas fichu de se gérer correctement, y a plus qu'à fermer le ban !

Ce que tu décris là me fait penser à des pannes aléatoires d'un disque dur en fin de vie.

@CosmoKnacki : t'as rien de moins flippant ?

Ceci étant dit, moi, ça me fait plutôt penser à un service qui n'aurait pas réussi à se lancer, pour une raison qui me dépasse mais qui pourrait être proche de cette manie stupide de vouloir démarrer tous les services en même temps, manip assez récente depuis quelques années et qui ne m'inspire pas confiance.

Ne perdez pas votre temps avec ce post, c'est juste un "coup de gueule".

Bonne année à tous, sans bugs et sans pannes,

PS : le forum m'a envoyé un courriel à propos de vos réponses, donc tout va mieux !

[Artemus24]

@ Jipété : je soupçonne un problème avec la pile Wayland.
Plus précisément avec le presse-papier qui est géré par le compositeur.
Si une application garde la main sur le presse-papier et se bloque, toute ta session graphique GNOME se fige.
Cela n'impacte pas la session Debian Trixie puisque tu peux encore faire un shutdown.
Je ne rencontre pas ton problème car même si je suis dans Debian Trixie, j'utilise encore X11, pas Wayland.

Je te conseille de ne plus utiliser WAYLAND et de basculer dans X11 (GNOME sous Xorg).
Tu te déconnectes de ta session actuelle.
Quand tu es dans l'écran de connexion (GDM), tu cliques sur ton nom d'utilisateur.
En bas à droite, il y a une roue dentée que tu vas cliquer dessus.
Tu cliques sur le choix "Gnome sur Xorg".
Après cela, tu te connectes.

Pour vérifier que tu es bien maintenant dans X11, tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $XDG_SESSION_TYPE

tu dois voir apparaitre X11.
Ceci est juste un test.

Si tu veux démarrer tout le temps sous X11, il faut modifier le fichier "/etc/gdm3/custom.conf".
Tu cherches la ligne "#WaylandEnable=false", que tu vas décommenter.
Tu sauvegardes le fichier et tu redémarres seulement GDM :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo systemctl restart gdm3

Ou plus simplement, tu fais un reboot.
A partir de maintenant, tu seras toujours sous X11 et plus du tout sous Wayland.

[Jipété]

Cela n'impacte pas la session Debian Trixie puisque tu peux encore faire un shutdown.

Le shutdown est hardware, en appuyant 5 secondes sur le bouton Power...

Je te conseille de ne plus utiliser WAYLAND et de basculer dans X11 (GNOME sous Xorg).

Cool : je ne l'ai jamais utilisé, sauf quand c'est la machine qui le fait dans mon dos et sans me demander mon avis, si tant est que ça soit possible.
La preuve, je rentre de promenade, je rallume la machine, qui avait été complètement éteinte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
echo $XDG_SESSION_TYPE
x11

Et aussi

Si tu veux démarrer tout le temps sous X11, il faut modifier le fichier "/etc/gdm3/custom.conf".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
cat /etc/gdm3/custom.conf
cat: /etc/gdm3/custom.conf: Aucun fichier ou dossier de ce type

Rien de plus à dire si ce n'est que j'insiste pour ne pas vous faire perdre votre temps.

[Artemus24]

Rien de plus à dire si ce n'est que j'insiste pour ne pas vous faire perdre votre temps.

Tu ne nous fait pas perdre notre temps. Un forum est destiné à s'entraider dans la mesure de nos moyens.
Il se peut que tout problème soit tout autre.

J'ai abordé la question de Wayland car j'ai rencontré plusieurs problèmes aussi bien avec mes Raspberry Pi qu'avec mon Asus sous Debian Trixie.
C'est pourquoi, je ne l'utilise plus tant qu'il ne sera pas finalisé.

[N_BaH]

Si tu veux démarrer tout le temps sous X11, il faut modifier le fichier "/etc/gdm3/custom.conf".
Tu cherches la ligne "#WaylandEnable=false", que tu vas décommenter.

je ne suis pas sûr que le fait que le gestionnaire de connexion utilise Wayland implique que le gestionnaire de fenêtre sera aussi sur Wayland.
j'ai "joué" récemment avec gdm3 pour qu'il utilise Wayland, et je me souviens (je n'ai pas une très bonne mémoire) qu'il m'était encore proposé de démarrer Gnome avec X11 ou avec Wayland.

[CosmoKnacki]

@CosmoKnacki : t'as rien de moins flippant ?

Désolé, c'est précisément ce qui c'est produit chez moi le mois dernier avec des symptômes similaires. Ça fait un peu vieux schnock de dire ça, et je l'ai entendu de la bouche de pas mal d'assembleurs: Les disques durs, c'est plus ce que c'étaient.

Bon ça vaut ce que ça vaut, mais c'est vrai qu'on atteint péniblement les 10 ans avec certains. C'est un peu la loterie. (D'ailleurs désormais je m'oriente vers des disques "spécial NAS" qui sont à mon avis plus durables).

Un passage par les outils smartmontools permettra de tester l'état de santé des disques et de lever quelques doutes.

[fred1599]

Hello,

Pouvez-vous confirmer avec les commandes suivantes :

Le fabricant de la carte mère : sudo dmidecode -s baseboard-manufacturer

Le modèle précis de votre carte mère : sudo dmidecode -s baseboard-product-name

La politique ALPM actuelle du noyau : cat /sys/class/scsi_host/host*/link_power_management_policy

Si vous ne trouvez pas la politique ALM, faut là chercher : find /sys/class/scsi_host/ -name "link_power_management_policy"

La présence du pilote AHCI : lspci -k | grep -iA 2 "sata"

Si rien de trouver toujours pour la politique ALPM, on peut voir cela peut-être dans les logs de démarrage : sudo dmesg | grep -i "lpm"

Des erreurs liées au SATA qui expliqueraient pourquoi la gestion d'énergie est désactivé : sudo dmesg | grep -iE "ahci|sata|ata" | grep -i "error"

Si le fichier link_power_management_policy est absent, cela peut signifier deux choses :

• Bonne nouvelle : La gestion agressive de l'énergie (ALPM) n'est peut-être pas active, donc elle n'est pas la cause de vos gels.
• Mauvaise nouvelle : Votre contrôleur SATA fonctionne dans un mode dégradé (IDE/Legacy) qui pourrait lui-même être la source de lenteurs ou de conflits avec Debian 12.

Les recherches indiquent une prévalence élevée d'incompatibilités entre les implémentations BIOS de Gigabyte et les politiques d'énergie par défaut du noyau Linux moderne. Ces cartes mères activent souvent par défaut des fonctionnalités comme le "Hot Plug" ou l'ALPM au niveau du BIOS, sans fournir les tables ACPI correctes au noyau pour gérer les transitions d'état, créant un terrain fertile pour les blocages d'I/O.

https://forums.tomshardware.com/thre...ooted.3782993/
https://download1.gigabyte.com/Files...81a678e4906c9a

J'attends la confirmation des commandes pour pouvoir en dire plus...

[Jipété]

Bonjour,

Pouvez-vous confirmer avec les commandes suivantes :

Le fabricant de la carte mère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Gigabyte Technology Co., Ltd

.

Le modèle précis de votre carte mère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B450M S2H

La politique ALPM actuelle du noyau : cat /sys/class/scsi_host/host*/link_power_management_policy:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
max_performance
max_performance
max_performance
max_performance
max_performance
max_performance
max_performance
max_performance
med_power_with_dipm
med_power_with_dipm

Si vous ne trouvez pas la politique ALM, faut là chercher : find /sys/class/scsi_host/ -name "link_power_management_policy"

Je l'ai donc trouvée mais comme je suis curieux, j'ai aussi lancé cette commande, pour voir, et elle ne remonte rien.

La présence du pilote AHCI : lspci -k | grep -iA 2 "sata"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01)
	Subsystem: ASMedia Technology Inc. 400 Series Chipset SATA Controller
	Kernel driver in use: ahci
	Kernel modules: ahci
--
0a:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 61)
	Subsystem: Gigabyte Technology Co., Ltd FCH SATA Controller [AHCI mode]
	Kernel driver in use: ahci
	Kernel modules: ahci

Si rien de trouvé toujours pour la politique ALPM, on peut voir cela peut-être dans les logs de démarrage : sudo dmesg | grep -i "lpm"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
[   10.495759] usb usb2: We don''t know the algorithms for LPM for this host, disabling LPM.
[   10.502867] usb usb4: We don''t know the algorithms for LPM for this host, disabling LPM.
[   10.504922] usb usb6: We don''t know the algorithms for LPM for this host, disabling LPM.

Des erreurs liées au SATA qui expliqueraient pourquoi la gestion d'énergie est désactivée : sudo dmesg | grep -iE "ahci|sata|ata" | grep -i "error"

Cette commande ne remonte rien, ce matin (et pour les autres jours je n'en sais rien, c'est la première fois que je l'utilise).

Si le fichier link_power_management_policy est absent, cela peut signifier deux choses : ...

Fichier présent, voir + haut.

Enfin, le premier des deux liens en bas de post parle de "PC freezes if no processes are running, needs to be rebooted", ce qui n'est pas exactement mon cas, le freeze se produisant habituellement au lancement d'une fenêtre "Explorer", je dirais, si j'étais sous Windows.
Quant au second lien, je ne sais qu'en faire...

Mais merci quand même, surtout pour le temps passé à essayer de dépatouiler tout ça (perso, j'avoue que ça me démoralise et que j'ai beaucoup plus vite fait de faire Power-Off, attendre 10 secondes, Power-On et ça repart.
Par ailleurs, il arrive que ça ne soit pas complètement freezed : je passe en mode console, je m'y logge et je peux bricoler des trucs, en général fermer proprement les fichiers ouverts puis reboot.

Bon dimanche, ne passez pas trop de temps là-dessus.

[fred1599]

Tout se confirme...

La commande cat /sys/class/scsi_host/host*/link_power_management_policy a renvoyé :

• 8 ports en max_performance (Stable)
• 2 ports en med_power_with_dipm (Zone de risque)

C'est ici que se situe le problème. La valeur med_power_with_dipm (politique d'économie d'énergie agressive) sous le noyau Linux 6.1 provoque des gels sur les contrôleurs SATA de certaines cartes mères, notamment les modèles Gigabyte. Puisque vous possédez 1 SSD et 2 HDD, au moins l'un de ses disques est géré par un port utilisant cette politique instable.

Vous dîtes que le freeze se produit au lancement d'une fenêtre de navigation de fichiers. Cela correspond exactement au scénario où :

1. Le système demande au disque de sortir de son état d'économie d'énergie (med_power).
2. Le contrôleur SATA Gigabyte échoue à gérer la transition d'état via le pilote AHCI.
3. Le bus SCSI se bloque, entraînant un "I/O Wait" infini, ce qui fige l'interface X11.

À partir des noyaux 4.15+, le paramètre CONFIG_SATA_MOBILE_LPM_POLICY a été réglé par défaut sur 3 (med_power_with_dipm) pour les chipsets identifiés comme mobiles.
De nombreuses cartes mères Gigabyte (dont la série B450) exposent des tables ACPI qui induisent le noyau en erreur, lui faisant appliquer cette politique mobile sur une station fixe.
Le mode med_power_with_dipm permet au disque (DIPM) d'initier une mise en veille profonde. Sur les chipsets AMD 400 et certains contrôleurs ASMedia, la négociation de réveil (COMWAKE) échoue souvent, entraînant un blocage définitif du contrôleur SATA.

L'erreur After module unload, module 'module-null-sink' was still loaded! n'est pas la cause, mais une conséquence directe de la latence du bus système.

• Lorsqu'un conflit SATA survient, le bus PCI subit un pic de latence massif.
• Le serveur audio, qui a des contraintes de temps réel strictes, est le premier à "décrocher". Il décharge le pilote matériel devenu injoignable et bascule sur le null-sink virtuel.
• Cette trace dans vos logs est donc la preuve d'un incident matériel survenu quelques millisecondes avant que le noyau ne se fige en tentant d'écrire sur le disque bloqué.

Le paramètre ahci.mobile_lpm_policy=1 est la méthode standard et recommandée pour désactiver l'ALPM au niveau du pilote AHCI.

• Valeur 0 : Respecte les réglages du firmware BIOS (souvent instable si le BIOS Gigabyte force l'ALPM en arrière-plan).
• Valeur 1 : Force le mode max_performance (désactive l'ALPM), garantissant que le lien SATA reste actif en permanence et évitant ainsi les échecs de réveil.
• Alternative NCQ : L'ajout de libata.force=noncq est une sécurité supplémentaire pertinente pour les disques durs mécaniques plus anciens qui gèrent mal la file d'attente des commandes lors des pics de latence.

La structure monolithique de X11 explique pourquoi le système semble "totalement mort" lors de ces incidents. Sous X11, si le thread principal du serveur d'affichage attend une réponse d'E/S (pour écrire un log ou charger une icône), l'intégralité de la boucle d'événements (clavier, souris) se fige.

Voici une solution,

Avant de modifier le chargeur de démarrage, on crée une copie de sauvegarde : sudo cp /etc/default/grub /etc/default/grub.bak

Il faut éditer le fichier de configuration de GRUB : sudo nano /etc/default/grub

Dans l'éditeur, cherchez la ligne commençant par GRUB_CMDLINE_LINUX_DEFAULT. Elle ressemble probablement à ceci : GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Ajoutez le paramètre ahci.mobile_lpm_policy=1 à l'intérieur des guillemets. La ligne finale doit ressembler à : GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ahci.mobile_lpm_policy=1"

Note : La valeur 1 force le mode "max_performance", désactivant ainsi la mise en veille instable du lien SATA.

Pour que Debian prenne en compte la modification, lancez la mise à jour de GRUB puis redémarrez la machine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sudo update-grub
sudo reboot

Une fois le système redémarré, vérifiez que la mauvaise politique a disparu : cat /sys/class/scsi_host/host*/link_power_management_policy

Tous les ports doivent maintenant afficher max_performance. Si c'est le cas, les gels lors des copier/coller ou des manipulations de fichiers ne devraient plus se produire.

Si les gels persistent,

Dans de rares cas sur les vieux HDD, la gestion des files d'attente (NCQ) peut aussi poser problème. Si le bug revient, vous pouvez ajouter un second paramètre à la même ligne GRUB : GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ahci.mobile_lpm_policy=1 libata.force=noncq"

L'erreur PulseAudio (module-null-sink) disparaîtra d'elle-même, car elle n'était qu'une victime collatérale du blocage du bus disque à mon sens...

[Jipété]

Une fois le système redémarré, vérifiez que la mauvaise politique a disparu : cat /sys/class/scsi_host/host*/link_power_management_policy

Et c'est bien le cas !

Bravo, Fred, voilà une année qui commence bien.

Je stocke dans un coin le complément de solution, okazou. On n'est jamais trop prudent.

Et comme on dit, il vaut mieux un qui sait que dix qui cherchent !
Encore merci, d'autant plus qu'au départ, je ne voyais vraiment pas comment arriver à une bonne solution : c'est pas trop mon truc, les mains dans le cambouis, même si bien piloté (et ce fut le cas), je ne me perds pas, le tout c'est de trouver la bonne porte d'entrée.

[fred1599]

Top, ça coûte moins cher qu'un disque dur 😉

[LittleWhite]

Bonjour,

Je suivais la discussion et je me demandais, mais comment vous savez tout ça fred1599 ? Je veux dire, c'est ultra spécifique comme symptôme et certes, on pouvait penser à un problème en liant avec le disque dur, mais tout de même, le combo disque dur + carte mère + noyau et ainsi de suite, fallait le voir. En bref, comment avez vous été mis au courant d'un tel problème ?
En tout cas, bravo ! et content que le problème soit résolu .

[Artemus24]

Je me demande si Fred1599 ne serait pas une IA de nouvelle génération très sophistiquée ?
Bravo pour la solution.

[fred1599]

J'ai 22 ans de linux et je ne sais pas tout... L'IA lorsque je là guide, me permet d'avancer très vite dans des recherches précises. À partir de là, tout est que contrôles des informations reçues !

Ce que je sais : L'une des erreurs de diagnostic les plus fréquentes dans ce scénario est de considérer le sous-système audio comme l'instigateur du crash. Les journaux système montrent souvent des erreurs telles que alsa_write_data XRun state, snd_pcm_delay failed: Input/output error, et le chargement persistant du module-null-sink.

Conclusion : une erreur I/O selon les infos de Jépété me convenaient bien.

Je suis tombé sur ce type de forum avec l'ajout du terme SATA : https://unix.stackexchange.com/quest...t-output-error

J'ai continué à creuser de ce côté, toujours grâce à l'IA et Google, et à force d'informations complémentaires, j'ai pu créer ma proposition de solution qui tenait la route.

Ce n'est qu'un gros travail de recherches, pas des connaissances, le tout est de ne pas raconter n'importe quoi et vérifier les sources.

Difficile de donner tous les détails de mes recherches, c'est comme des indices que vous récupérez petit à petit.

[fred1599]

Je me demande si Fred1599 ne serait pas une IA de nouvelle génération très sophistiquée ?
Bravo pour la solution.

On peut dire ça, c'est l'utilisation de l'IA a bon escient, c'est nous, génération 40 à 60 ans et plus qui avons le pouvoir de rendre l'IA utile grâce à nos expériences.
J'ai mis suffisamment la main dans le cambouis pour éviter les âneries que pourraient me proposer l'IA...

[Artemus24]

@ Fred1599 : j'ai pourtant posé la question à ChatGPT et il m'a répondu Wayland.
Comme j'avais eu des problèmes avec lui, j'ai pensé que la solution était de basculer en X11 (GNOME sous Xorg).
Je ne suis pas assez expérimenté en Linux, à l'inverse de toi, mais j'arrive a m'en sortir dans mes problèmes.
Je n'ai pas les automatismes comme par exemple sur l'économiseur d'énergie car je n'ai jamais eu ce genre de problème.
J'aurai dû penser que le disque pouvait être désactivé, mais cela me semblait bizarre puisque l'OS était opérationnel.
Combien de disques a Jipété dans son ordinateur ?

Même si l'on pratique Debian, nous n'avons pas tous la même expérience en ce domaine.