Debian/Sid sur "gros" ordinateur de bureau - plantage =c3=a9conomiseur d'=c3=a9cran donc comment vidanger sur disque SSD

Le
Basile Starynkevitch
Bonjour


Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper
2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé,
12 Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes
graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0,
xorg 2:1.20.8

En général, elle est peu chargée. J'y développe actuellement
https://github.com/bstarynk/helpcovid/

Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
chercher pourquoi, mais mon intuition est un économiseur d'écran qui
plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou un
truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
l'économiseur d'écran tournait!


J'ai par ailleurs chaque jour le mél automatique suivant:

> This message was generated by the smartd daemon running on:
>
> host name: rimski
> DNS domain: lesours
>
> The following warning/error was logged by the smartd daemon:
>
> Device: /dev/nvme0, number of Error Log entries increased from 535 to 536
>
> Device info:
> Samsung SSD 970 EVO 2TB, S/N:S464NB0KA03837J, FW:2B2QEXE7, 2.00 TB
>
> For details see host's SYSLOG.

De ce que j'en comprends, c'est l'usure normale d'un disque SSD. Quand
je lance (chaque mois) à la main

> rimski# smartctl -t short /dev/nvme0n1
> smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.0-1-amd64] (local build)
> Copyright (C) 2002-19, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> NVMe device successfully opened
>
puis

> rimski# smartctl -a /dev/nvme0n1
> smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.0-1-amd64] (local build)
> Copyright (C) 2002-19, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> START OF INFORMATION SECTION
> Model Number:                       Samsung SSD 970 EVO 2TB
> Serial Number:                      S464NB0KA03837J
> Firmware Version:                   2B2QEXE7
> PCI Vendor/Subsystem ID:            0x144d
> IEEE OUI Identifier:                0x002538
> Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
> Unallocated NVM Capacity:           0
> Controller ID:                      4
> Number of Namespaces:               1
> Namespace 1 Size/Capacity:          2,000,398,934,016 [2.00 TB]
> Namespace 1 Utilization:            297,127,981,056 [297 GB]
> Namespace 1 Formatted LBA Size:     512
> Namespace 1 IEEE EUI-64:            002538 5a81b50e6f
> Local Time is:                      Mon Apr 13 14:52:45 2020 MEST
> Firmware Updates (0x16):            3 Slots, no Reset required
> Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
> Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero
> Sav/Sel_Feat Timestmp
> Maximum Data Transfer Size:         512 Pages
> Warning  Comp. Temp. Threshold:     82 Celsius
> Critical Comp. Temp. Threshold:     82 Celsius
>
> Supported Power States
> St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat Ex_Lat
>  0 +     6.20W       -        -    0  0  0  0 0       0
>  1 +     4.30W       -        -    1  1  1  1 0       0
>  2 +     2.10W       -        -    2  2  2  2 0       0
>  3 -   0.0400W       -        -    3  3  3  3 210    1200
>  4 -   0.0050W       -        -    4  4  4  4 2000    8000
>
> Supported LBA Sizes (NSID 0x1)
> Id Fmt  Data  Metadt  Rel_Perf
>  0 +     512       0         0
>
> START OF SMART DATA SECTION
> SMART overall-health self-assessment test result: PASSED
>
> SMART/Health Information (NVMe Log 0x02)
> Critical Warning:                   0x00
> Temperature:                        45 Celsius
> Available Spare:                    100%
> Available Spare Threshold:          10%
> Percentage Used:                    0%
> Data Units Read:                    255,508,747 [130 TB]
> Data Units Written:                 8,230,365 [4.21 TB]
> Host Read Commands:                 1,555,762,509
> Host Write Commands:                82,030,381
> Controller Busy Time:               2,108
> Power Cycles:                       249
> Power On Hours:                     1,138
> Unsafe Shutdowns:                   186
> Media and Data Integrity Errors:    0
> Error Information Log Entries:      536
> Warning  Comp. Temperature Time:    0
> Critical Comp. Temperature Time:    0
> Temperature Sensor 1:               45 Celsius
> Temperature Sensor 2:               49 Celsius
>
> Error Information (NVMe Log 0x01, max 64 entries)
> No Errors Logged
>

Donc je ne m'inquiète pas. Devrais-je m'inquiéter?

dmesg | grep nvm me donne

> [    1.320357] nvme nvme0: pci function 0000:41:00.0
> [    1.541104] nvme nvme0: missing or invalid SUBNQN field.
> [    1.541204] nvme nvme0: Shutdown timeout set to 8 seconds
> [    1.572816] nvme nvme0: 32/0/0 default/read/poll queues
> [    1.582443]  nvme0n1: p2 p3 p4 < p5 >
> [    7.544896] EXT4-fs (nvme0n1p3): mounted filesystem with ordered
> data mode. Opts: (null)
> [    7.843577] EXT4-fs (nvme0n1p3): re-mounted. Opts: errors=remount-ro
> [    8.260884] EXT4-fs (nvme0n1p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [    8.539560] EXT4-fs (nvme0n1p5): mounted filesystem with ordered
> data mode. Opts: (null)

et mount | grep nvm me donne

> /dev/nvme0n1p3 on / type ext4 (rw,relatime,errors=remount-ro)
> /dev/nvme0n1p3 on /gentoo/tmp type ext4 (rw,relatime,errors=remount-ro)
> /dev/nvme0n1p2 on /boot type ext4 (rw,relatime)
> /dev/nvme0n1p5 on /home type ext4 (rw,relatime)
> /dev/nvme0n1p5 on /usr/src type ext4 (rw,relatime)

Mais je suis au courant de https://en.wikipedia.org/wiki/Page_cache et
http://man7.org/linux/man-pages/man2/sync.2.html et
https://www.linuxatemyram.com/ et
http://man7.org/linux/man-pages/man3/sleep.3.html

Je n'aime pas perdre des fichiers, notamment sous emacs. Un fsck sur SSD
est rapide, mais peut perdre des fichiers récents.

Il y a-t-il un moyen de vidanger les tampons du noyau vers le disque SSD
toutes les secondes, autrement qu'en écrivant le petit programme C (ou
le shell script) qui boucle indéfiniment sur sync(); suivi de sleep(1);

Je connais mal systemd.


Librement

--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; <basile@starynkevitch.net>
(mobile phone: cf my web page / voir ma page web)
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Michel OLTRA
Le #26543155
Bonjour,
Le lundi 13 avril 2020, Basile Starynkevitch a écrit...
Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper
2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé, 12
Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes graphiques (AMD
Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0, xorg 2:1.20.8
En général, elle est peu chargée. J'y développe actuellement

Sur les Ryzen (j'ai un Ryzen 5), il y a un problème de gel de la machine lié
à un certain état du processeur. J'ai vu des discussions sur les 5 et les 7.
Pour le tien, je ne sais pas. Sur noyaux 4.x et 5.x, par ailleurs.
Si ça peut être ça, chercher "ryzen linux kernel freeze when idle" par
exemple. Chez moi, la solution a été avec le script zenstates.py.
--
jm
Michel
Le #26543154
Le 13/04/2020 à 15:10, Basile Starynkevitch a écrit :
Bonjour
Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper
2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé,
12 Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes
graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0,
xorg 2:1.20.8
En général, elle est peu chargée. J'y développe actuellement
https://github.com/bstarynk/helpcovid/
Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
chercher pourquoi, mais mon intuition est un économiseur d'écran qui
plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou un
truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
l'économiseur d'écran tournait!


Bonjour Basile,
J'avais ce type de problème sur un portable ( Asus ROG G53SX, avec carte
Nvidia GeForce GT 560M ), freezes aléatoires là aussi. J'avais testé
plusieurs choses sans succès, puis j'ai désinstallé light-locker et tout
est rentré dans l'ordre.
Sans garantie, mais ça ne coûte rien d'essayer.
hamster
Le #26543159
Le 13/04/2020 à 15:06, Basile Starynkevitch a écrit :
Ma machine à la maison est une "grosse" machine: AMD Ryzen
Threadripper 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM,
boitier bien ventilé, 12 Tera de disque dont un Samsung SSD 970 EVO
2TB, deux cartes graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti).
Noyau Linux 5.5.0, xorg 2:1.20.8
En général, elle est peu chargée. J'y développe actuellement
https://github.com/bstarynk/helpcovid/
Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
chercher pourquoi, mais mon intuition est un économiseur d'écran qui
plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou
un truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
l'économiseur d'écran tournait!

Ca ne répond pas a ta question mais l'économiseur d'écran c'était un
truc fait pour économiser les tubes cathodiques. Avec un écran LCD (ou
autre technologie d'écran plat) ca fait travailler le processeur pour rien.
A moins que tu n'ait encore un vieil écran cathodique (ce donc je doute)
il vaut bien mieux configurer ton ordi pour qu'il eteigne l'écran au
bout d'un temps d'inactivité.
Personnellement, je désinstalle systématiquement l'économiseur d'écran a
chaque fois que je met debian sur un ordi. Je ne comprend d'ailleurs pas
qu'une vieillerie caduque comme l'économiseur d'écran soit toujours
installée et activée par défaut dans les distribs. Zut a la fin, on est
au 21e siècle !
Jean-Michel OLTRA
Le #26543167
Bonjour,
Le lundi 13 avril 2020, BERTRAND Joël a écrit...
Je rebondis un peu sur le sujet, désolé de me greffer dans la
discussion. J'ai parcouru un peu les archives internet et je n'arrive
pas à avoir une idée claire. J'envisage de changer ma machine de bureau
justement pour un Ryzen 7 ou 9, mais sans GPU intégré (il me faut une
carte graphique de 2 ou 4 Go pour travailler sereinement). Est-ce que ce
bug se limite aux CPU avec GPU intégré (utilisés ou non) ou à tous les
Ryzen ?

Il y a un sujet fleuve sur kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id6683
Il y a un moment que je ne l'ai pas parcouru.
De mémoire, certains on fait pas mal de tests avec de CM et des cartes
graphiques différentes, mais les résultats n'étaient pas probants. J'ai une
MSI B350M. Il me semble que la version du bios de l'époque (il y a 1 an et
demi) était plus ou moins en cause. Quant aux Ryzen, je pense que les 7
sont également touchés. Les 9, je ne sais pas. En CM, j'éviterais MSI avec
les Ryzen. Le script zenstates.py fait bien le job en désactivant l'état c6
du processeur, je ne suis plus ennuyé avec ça depuis que systemd l'active au
boot.
--
jm
Basile Starynkevitch
Le #26543390
On 15/04/2020 19:40, Dominique Dumont wrote:
On lundi 13 avril 2020 16:16:10 CEST BERTRAND Joël wrote:
Je rebondis un peu sur le sujet, désolé de me greffer dans la
discussion. J'ai parcouru un peu les archives internet et je n'arrive
pas à avoir une idée claire. J'envisage de changer ma machine de bureau
justement pour un Ryzen 7 ou 9, mais sans GPU intégré (il me faut une
carte graphique de 2 ou 4 Go pour travailler sereinement). Est-ce que ce
bug se limite aux CPU avec GPU intégré (utilisés ou non) ou à tous les
Ryzen ?

J'ai eu ce problème de freeze aléatoire sur AMD Ryzen 7 1700X (sans GPU
intégré).
C'est maintenant résolu avec:
- l'option processor.max_cstate=1 au boot
- "Global C State control" disabled dans UEFI
Ceci pour une carte MSI X370 SLI plus. L'option "Global C State control" est
dans le menu "over clocking" -> CPU Features.
HTH


Depuis que j'ai désactivé tous mes économiseurs d'écran (les screen
lock) je n'ai plus aucun problème de stabilité
(carte mère MSI 399, AMD Threadripper 2970WX, deux cartes graphiques,
l'une AMD Radeon RX 570, l'autre Nvidia  GeForce GTX 1050)
(Linus Torvalds avait raison: Nvidia fuck you) - on trouve ça sur youtube
J'ai aussi des bonnes barettes mémoires.
La sortie de la commande sudo hwinfo sur ce gros ordinateur de bureau
est disponible en
http://starynkevitch.net/Basile/hwinfo-ours.starynkevitch.net.txt
et quand tout va bien certains amis peuvent s'y connecter par ssh
ours.starynkevitch.net
Il y a un onduleur, mais le souci concret est de faire tenir le cable
Ethernet (dans le connecteur Ethernet de la carte mère). J'ai essayé la
pate PatAFix sans succès. Ou le morceau d'allumettes. Sans succès!
Bonne soirée.

Librement
--
Basile Starynkevitch - http://starynkevitch.net/Basile/
Bourg La Reine, France opinions are only mine - les opinions sont seulement miennes
Publicité
Poster une réponse
Anonyme