Debian/Sid sur "gros" ordinateur de bureau - plantage =c3=a9conomiseur d'=c3=a9cran donc comment vidanger sur disque SSD
5 réponses
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...)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Michel OLTRA
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
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.
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 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.
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.
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 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 !
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 !
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
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
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.
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
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
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é
(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 <basile@starynkevitch.net>
opinions are only mine - les opinions sont seulement miennes
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
