Depuis que je suis sous Debian 12 Gnome j’aimerais avoir ce BSOD, ça serait plus joli que mon écran qui se fige. Pour l’instant j’ai remarqué que ça se produisait après les mises en veille, pas immédiatement mais quasiment systématiquement. Cela peut se produire après une reprise de plusieurs dizaines de mn. Où chercher pour avoir une idée du problème ? Ma solution : j’ai désactivé la mise en veille et j’arrete mon ordi si je ne dois pas l’utiliser pendant plus d’une heure…
Bonjour, je rencontre également ce plantage à la mise en veille depuis que j’ai installé Débian 12 Gnome le 2 décembre à Châteaulin.
J’ai aussi des fermetures intempestives de firefox que je n’ai pas réussi à corréler avec quoi que ce soit.
Denis
Dans les deux cas, il faudrait une identification précise du matériel…
Un outil sympa pour ça : hw-probe (avec le site associé https://linux-hardware.org )
La première intuition pourrait s’intéresser au noyau utilisé (je ne connais pas la gestion Debian des versions noyaux)
Merci
J’espère que comme il le dise, mes données seront anonymisées…
Deux de mes disques durs sont identifiés comme " The S.M.A.R.T. errors are detected. It’s recommended to replace the drive soon.
alors que « Disques » de Gnome m’indique que ces disques sont sains mais pour l’un qu’un attribut avait déjà défailli avant et pour l’autre qu’un secteur est endommagé.
Ils ne sont pas jeunes et peut-être il faudrait que j’envisage de les remplacer ?
Sinon je ne sais pas si ça me donne des éléments pour comprendre pourquoi mon écran se fige.
le noyau est 6.1.0-13-amd64
Continuer à surveiller, dans un terminal :
sudo journalctl -u smartmontools.service -f
quand smart-notifier est installé, on peut recevoir une notification mail avec par exemple le nombre d’erreurs récentes. Si ce nombre augmente continuellement, problème…
Pour les défaillances aléatoires, il y a aussi les problèmes de RAM… De mauvaises lectures => plantage d’applications…
Et un test longue durée en clé live ?
une clé live ne sollicite pas les disques durs, ça peut faire le tri …
Merci @ValLibre
Pour nos écrans figés lors du retour de veille, je peux me connecter en ssh à partir d’un autre ordi mais je reste comme une poule qui a trouvé un couteau… sans savoir quoi chercher
S’il n’y a pas eu de reboot, une piste, via ssh, c’est
sudo dmesg -T --level=err
ça donne une liste datée de message bas niveau avec parfois des indices…
Le man de dmesg est utile.
Je viens de sortir de veille. L’écran n’est pas encore figé mais voila le résultat de sudo dmesg -T --level=err
Je découvre. Est-ce normal ?
[dim. 10 déc. 08:35:30 2023] DMAR: DRHD: handling fault status reg 2
[dim. 10 déc. 08:35:30 2023] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 08:35:43 2023] firmware_class: See Firmware - Debian Wiki for information about missing firmware
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: msvld: unable to load firmware data
[dim. 10 déc. 08:35:43 2023] nouveau 0000:01:00.0: msvld: init failed, -19
[dim. 10 déc. 10:41:19 2023] scsi 8:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 10:41:19 2023] scsi 8:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 10:41:19 2023] scsi 8:0:0:1: Failed to bind enclosure -19
[dim. 10 déc. 10:42:42 2023] Aborting journal on device sdf3-8.
[dim. 10 déc. 10:42:42 2023] Buffer I/O error on dev sdf3, logical block 50888704, lost sync page write
[dim. 10 déc. 10:42:42 2023] JBD2: I/O error when updating journal superblock for sdf3-8.
[dim. 10 déc. 10:46:07 2023] ses 8:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 10:46:07 2023] ses 8:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 10:46:07 2023] ses 8:0:0:1: Failed to bind enclosure -19
Il semble évident que ça patouille côté firmware/carte graphique, ce qui est conforme au fait que c’est le réveil graphique qui ne se fait pas (ssh opérationnel)
L’intuition qu’on est bien sur la bordure grise Debian…
« Nouveau » n’est pas la meilleure solution pour reconnaître un maximum de carte graphique, mais c’est le choix (cohérent) Debian…
sudo apt-get install firmware-misc-nonfree
?
Avant de chercher à installer des pilotes proprios, moi je fais généralement le test de virer carrément nouveau (xserver-xorg-video-nouveau), il est possible que le résultat graphique soit satisfaisant sans nécessairement activer toute la puissance de la carte nvidia. C’est selon l’usage évidemment
Là j’ai le résultat après retour de veille et écran figé
[dim. 10 déc. 09:48:03 2023] DMAR: DRHD: handling fault status reg 2
[dim. 10 déc. 09:48:03 2023] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 09:48:16 2023] firmware_class: See Firmware - Debian Wiki for information about missing firmware
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: msvld: unable to load firmware data
[dim. 10 déc. 09:48:16 2023] nouveau 0000:01:00.0: msvld: init failed, -19
[dim. 10 déc. 11:53:52 2023] scsi 8:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 11:53:52 2023] scsi 8:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 11:53:52 2023] scsi 8:0:0:1: Failed to bind enclosure -19
[dim. 10 déc. 11:55:15 2023] Aborting journal on device sdf3-8.
[dim. 10 déc. 11:55:15 2023] Buffer I/O error on dev sdf3, logical block 50888704, lost sync page write
[dim. 10 déc. 11:55:15 2023] JBD2: I/O error when updating journal superblock for sdf3-8.
[dim. 10 déc. 11:58:40 2023] ses 8:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 11:58:40 2023] ses 8:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 11:58:40 2023] ses 8:0:0:1: Failed to bind enclosure -19
[dim. 10 déc. 13:02:50 2023] nouveau 0000:01:00.0: DRM: core notifier timeout
[dim. 10 déc. 13:02:59 2023] nouveau 0000:01:00.0: DRM: base-1: timeout
[dim. 10 déc. 13:03:01 2023] nouveau 0000:01:00.0: DRM: base-1: timeout
Les trois dernières lignes confirment bien le problème du pilote nouveau.
Pour le fun : copier coller la ligne
nouveau 0000:01:00.0: DRM: core notifier timeout
dans chatgpt 
La réponse n’est pas débile…
Sur les questions de ce type, Chatgpt est une synthèse automatique des réponses les plus courantes.
Oui la réponse de ChatGPT est claire 
L'erreur que vous rencontrez est liée au pilote graphique open-source "nouveau" pour les cartes graphiques NVIDIA. Le message indique qu'il y a un délai d'attente (timeout) dans le gestionnaire de rendu DRM (Direct Rendering Manager).
Voici quelques étapes que vous pouvez essayer pour résoudre ce problème :
Redémarrage du système : Essayez de redémarrer votre système. Parfois, les problèmes temporaires peuvent être résolus en redémarrant simplement.
Mise à jour des pilotes graphiques : Assurez-vous que vous utilisez la dernière version du pilote "nouveau" en mettant à jour votre système. Cela dépend de la distribution Linux que vous utilisez. Pour Debian/Ubuntu, vous pouvez utiliser la commande :
bash
sudo apt-get update
sudo apt-get upgrade
Pour les distributions basées sur Red Hat (comme Fedora), vous pouvez utiliser :
bash
sudo dnf update
Utilisation des pilotes propriétaires NVIDIA : Si les problèmes persistent, vous pourriez envisager d'installer les pilotes graphiques propriétaires NVIDIA. Cela dépend de votre distribution Linux. Par exemple, sur Ubuntu, vous pouvez utiliser le programme "Logiciels et mises à jour" pour installer les pilotes propriétaires.
Désactivation du mode KMS (Kernel Mode Setting) : Vous pouvez essayer de désactiver le mode KMS en ajoutant la ligne suivante au fichier de configuration du chargeur d'amorçage (par exemple, GRUB) :
bash
nouveau.modeset=0
Assurez-vous de bien comprendre comment modifier la configuration du chargeur d'amorçage sur votre distribution.
Examen des journaux système : Vous pouvez examiner les journaux système pour plus d'informations sur l'erreur. Utilisez la commande suivante pour afficher les derniers messages du journal :
bash
dmesg | tail
Recherchez des messages d'erreur ou d'avertissement liés à "nouveau" ou à votre carte graphique.
Si aucune de ces étapes ne résout le problème, vous pourriez envisager de consulter les forums de support de votre distribution Linux ou le site web de la communauté Ubuntu ou Fedora, selon votre cas. Les problèmes spécifiques au matériel et aux pilotes peuvent souvent être résolus avec l'aide de la communauté.
Juste pour préciser : il n’y a pas deux réponses identique de chatgpt pour la même question… L’algorithme n’est pas déterministe.
Je n’ai pas eu exactement la même chose (rien sur Fedora). Ajouter des mots clés genre Debian 12 peut encore affiner.
Attention : il faut quand même comprendre et évaluer ce qu’il demande de faire
1 « J'aime »
Nvidia propose un peu la même chose pour désactiver nouveau
blacklist nouveau
options nouveau modeset=0
dans /etc/modprobe.d/blacklist.conf
ou /etc/modprobe.d/disable-nouveau.conf
http://us.download.nvidia.com/XFree86/Linux-x86_64/470.223.02/README/commonproblems.html#nouveau
avec le fichier [spoiler]/etc/modprobe.d/blacklist.conf[/spoiler] (c’est /etc/modprobe.d/disable-nouveau.conf que j’ai utilisé) j’ai toujours les erreurs sur nouveau
Il ne serait pas désactivé ? Faut-il aller dans le Grub comme le conseille ChatGPT ?
[dim. 10 déc. 14:48:40 2023] DMAR: DRHD: handling fault status reg 2
[dim. 10 déc. 14:48:40 2023] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
[dim. 10 déc. 14:48:42 2023] scsi 7:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 14:48:42 2023] scsi 7:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 14:48:42 2023] scsi 7:0:0:1: Failed to bind enclosure -19
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 14:48:48 2023] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084 (-2)
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: firmware: failed to load nouveau/nve7_fuc084d (-2)
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: msvld: unable to load firmware data
[dim. 10 déc. 14:48:48 2023] nouveau 0000:01:00.0: msvld: init failed, -19
J’ai reposé la question à ChatGPT et voici sa réponse
Pour modifier les options de démarrage du noyau dans GRUB sous Debian 12 et désactiver le pilote nouveau pour la carte graphique en ajoutant nouveau.modeset=0, suivez ces étapes :
Ouvrez un terminal.
Éditez le fichier de configuration GRUB avec un éditeur de texte. Vous pouvez utiliser n'importe quel éditeur de texte que vous préférez, par exemple, nano ou vim. Pour ouvrir le fichier de configuration avec nano, vous pouvez utiliser la commande suivante (vous devrez peut-être utiliser sudo pour avoir les droits d'écriture) :
bash
sudo nano /etc/default/grub
Trouvez la ligne qui commence par GRUB_CMDLINE_LINUX et ajoutez nouveau.modeset=0 à la liste des options entre les guillemets. Par exemple, la ligne pourrait ressembler à ceci après modification :
bash
GRUB_CMDLINE_LINUX="nouveau.modeset=0 autre_option=une_valeur"
Assurez-vous de laisser les guillemets autour des options déjà présentes.
Enregistrez les modifications et fermez l'éditeur.
Après avoir modifié le fichier de configuration, mettez à jour GRUB en exécutant la commande suivante pour prendre en compte les modifications :
bash
sudo update-grub
Redémarrez votre système pour appliquer les changements.
Après le redémarrage, le noyau devrait être démarré avec l'option nouveau.modeset=0, désactivant ainsi le pilote nouveau pour la carte graphique. Assurez-vous que cette modification est compatible avec votre matériel et nécessaire pour résoudre le problème que vous rencontrez.
Je crois que c’est bon, je n’ai plus nouveau et je m’en rends compte
Je n’ai plus qu’un seul écran sur deux. Le lanceur de Gnome ne fonctionne plus et certaine fenètre ont du mal à se fermer 
Je vais essayer d’installer le pilote Nvidia
[dim. 10 déc. 15:05:38 2023] scsi 7:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 15:05:38 2023] scsi 7:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 15:05:38 2023] scsi 7:0:0:1: Failed to bind enclosure -19
J’ai installé le pilote Nvidia
et j’ai retrouvé mes deux écrans et un fonctionnement normal
pas plus d’erreur au redémarrage
[dim. 10 déc. 15:24:46 2023] scsi 7:0:0:1: Wrong diagnostic page; asked for 1 got 8
[dim. 10 déc. 15:24:46 2023] scsi 7:0:0:1: Failed to get diagnostic page 0x1
[dim. 10 déc. 15:24:46 2023] scsi 7:0:0:1: Failed to bind enclosure -19
Je vais faire le test de la veille
Je suis revenu à nouveau. Le pilote Nvidia faisait n’importe quoi…
Je vais essayer de me trouver une carte graphique qui soit mieux gérée par nouveau.
D’ici là je ferai des arrêts et plus de veille
Merci @ValLibre pour ton aide