Le noyau Linux 6.13 corrigera un problème de démarrage sur les machines AMD Zen 1 et 2
Le 03 décembre 2024 à 09h04
2 min
Hardware
Hardware
Le 6 novembre, un ingénieur de Nokia disait avoir remarqué un comportement étrange sur d’anciens serveurs contenant des processeurs EPYC d’AMD. Sur ces machines, le processus initramfs pouvait mettre beaucoup plus longtemps à démarrer, jusqu’à plusieurs dizaines de secondes, voire plusieurs minutes.
Comme le rapporte Phoronix, l’enquête sur le problème a permis de débusquer un vieux bug introduit il y a 18 mois dans la manière de gérer le microcode au sein des processeurs des générations Zen 1 et 2. Il ne s’agit donc pas d’un problème spécifique aux processeurs EPYC.

Plus en détail, il est nécessaire de vider le TLB (translation lookaside buffer) après mise à jour du microcode pour évacuer le mappage du tampon de la mise à jour. Un patch a donc été introduit avec l’étiquette x86/urgent, pour intégration dans le futur noyau 6.13, dont la Release Candidate 1 vient de paraître.
Les processeurs AMD de générations Zen 1 et 2 sont considérés aujourd’hui comme anciens (respectivement 2017 et 2019), mais sont encore largement utilisés. Linux étant souvent employé pour redonner « vie » à de vieilles configurations, le problème pourrait bien avoir été rencontré de nombreuses fois par les utilisateurs.
Le 03 décembre 2024 à 09h04
Commentaires (20)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 03/12/2024 à 10h08
Le 03/12/2024 à 14h44
sudo systemd-analyze blame
Tu pourras vérifier si tu n'as pas un service dont le temps de démarrage n'est pas anormalement long.
Le 04/12/2024 à 10h07
Le 04/12/2024 à 12h46
18.548s plocate-updatedb.service
ça me paraît long...
Le 04/12/2024 à 19h33
Le 04/12/2024 à 19h39
29408 -rw-r----- 1 root plocate 30113603 déc. 4 07:48 /var/lib/plocate/plocate.db
Le 04/12/2024 à 19h51
Modifié le 04/12/2024 à 21h26
du -h donne les tailles et taux d'occupation des espaces de stockage de ton système.
sudo ls -lAR / | wc -l liste de manière recursive les fichiers/répertoires depuis la racine du système et renvoie le décompte du nombre de lignes de cette liste
Si ce sont les bons ordres de grandeur et en fonction des perfs du stockage, fred42 a raison: ce n'est pas catastrophique même si ce n'est pas très rapide.
Si tu veux optimiser, tu peux exclure des dossiers de l'indexation via le fichier /etc/updatedb.conf mais RTFM avant d'y toucher (man updatedb.conf).
Mon ami duckduck me glisse aussi dans l'oreille que si tu as une distribution qui utilise des paquets apt, tu as plus de (mal)chance d'être dans les personnes qui remontent des lenteurs sur plocate ;-)
Modifié le 04/12/2024 à 21h40
Sinon, oui, apt (Mint).
Le 04/12/2024 à 21h50
sinon, il faut prendre la somme des espaces de toutes tes partitions.
32Go, pour moi, c'est presque une fresh install (ok, j'installe trop de choses) sans mes données (ok, je garde trop de chose en local)
Modifié le 04/12/2024 à 22h01
Modifié le 07/12/2024 à 22h30
26.616s udisks2.service
6.708s lvm2-monitor.service
5.394s systemd-udev-settle.service
3.900s NetworkManager-wait-online.service
2.349s zfs-load-module.service
Les autres services sont de l'ordre de la milliseconde. Le descriptif du service est :
"The udisks daemon serves as an interface to system block devices, implemented via D-Bus. It handles operations such as querying, mounting, unmounting, formatting, or detaching storage devices such as hard disks or USB thumb drives. "
Certes j'ai 4 disques et quelques partitions mais mon PC n'a rien d'un Datacenter non plus ^^ merci d'avance
Le 07/12/2024 à 22h41
Un disque usb attaché au moment du boot ?
Le 09/12/2024 à 09h02
Je peux tenter de le débrancher ou à terme le remplacer pour voir. Merci d'avoir continué la discussion quoi qu'il en soit ;-)
Le 03/12/2024 à 10h23
Le 03/12/2024 à 10h45
Aujourd'hui mon PC va sur ses 10 ans, et sans parler de bête de course, je l'utilise quotidiennement sans soucis, même pour des tâche relativement "pointues".
Le 03/12/2024 à 11h56
Je ne le classe pas du tout comme une vieille config, rendez-vous compte, 6 coeurs, 12 threads... J'ai une bête de course comparé à avant, très efficace pour bosser... Je me paie même le luxe de jouer dessus avec en 1080P/30fps (suffisant vu la taille de l'écran) avec du FSR, pour peu ou prou l'équivalence d'une PS4 selon les jeux...
Depuis qu'on a tant de ram, et des ssd, d'autant plus NVME, ça n'a aucun sens de dire qu'une config est dépassée, depuis au moins 2017. Pour la plupart des usages, c'est suffisant...
Moi j'ai changé parce que j'avais besoin de plus de ram et rapide pour gérer 3 navigateurs et des dizaines d'onglets ouvert + traitement graphique/vidéo et j'en passe... Même sous Linux. Et que je voulais un peu plus de perfs en 3D. (Faut dire qu'en plus à 500€, c'était une affaire.)
Le 03/12/2024 à 13h18
Le 04/12/2024 à 14h48
Quand j'ai commencé à bidouiller avec mon Celeron 400, je rachetais du matos très régulièrement.
Ma configuration actuelle (Threadripper 1950X) a 7 ans, j'ai juste changé ma carte graphique mais c'est tout.
Elle est tout à fait viable au quotidien et j'avais prévu de la conserver 4-5 ans.
Je pense changer de configuration l'année prochaine (pour le fun) et upgrader mon home server avec ma config actuelle.
Le 03/12/2024 à 22h20
https://www.phoronix.com/news/Linux-Zen1-Zen2-Slow-Boot-ucode