tmp a écrit 45 commentaires

En effet, on sent bien qu'il a eu la démarche de l'IA. Vous êtes indécrottables, je retourne parler avec une IA.

Je ne crois pas que ce soit du grand n'importe quoi. J'ai expliqué ma démarche, et posté le résultat de la démarche. Une erreur MCE n'est pas facile a diagnostiqué sans lire beaucoup de documentation. Ici l'IA, en l’occurrence ChatGPT est capable d'orienter la réflexion.

Si maintenant montrer (comme certain le faisaient avec "Google est ton ami") une démarche pour atteindre une certaine autonomie de diagnostique en utilisant des outils qui existent, te dérange, je te propose de continuer à "moinser" et éviter de m’interpeller en me tutoyant.

D'autre part, si la personne se reconnecte, on pourra savoir quoi de ton message ou du mien, l'a vraiment aidé.

Cela se passe à l'extinction du PC, reboot en boucle, puis ce message:

Très bien, cette précision change nettement l’analyse — et elle la rend plus cohérente avec ce matériel.

1️⃣ Ce scénario est typique et bien connu

Extinction → reboot en boucle → MCE au boot

Sur les HP 15-db0xxx avec AMD A-Series, c’est un schéma classique de défaillance matérielle marginale, pas d’un CPU “mort net”.

On n’est plus dans une panne franche, mais dans une perte de stabilité transitoire.

2️⃣ Pourquoi cela arrive précisément à l’extinction

À l’extinction / redémarrage :

le CPU change brutalement d’état C/P

les tensions CPU/RAM chutent

le contrôleur mémoire est réinitialisé

le contenu cache/RAM est invalidé

👉 C’est le moment le plus stressant électriquement pour :

l’IMC (Integrated Memory Controller)

la RAM

les VRM de la carte mère

Si un composant est en limite, c’est là qu’il décroche.

3️⃣ Lecture du MCE à la lumière de ce contexte

Bank 4 → mémoire / data fabric

ADDR valide

PCC=1

au tout début du boot

➡️ Le CPU détecte une incohérence mémoire dès la phase de remise sous tension, avant même que l’OS n’ait la main.

Ce n’est pas une erreur “pendant le travail”, mais au moment où l’électronique repart de zéro.

4️⃣ Causes les plus probables DANS CE CAS PRÉCIS
🥇 1. Barrette RAM fatiguée (très fréquent)

Sur HP entrée de gamme :

RAM souvent de qualité moyenne

vieillissement thermique

tolérances larges

👉 À chaud, ça tient.
👉 À froid ou lors des transitions, ça décroche.

🥈 2. Slot RAM / contacts

micro-oxydation

contraintes mécaniques

carte mère fine

Très courant après quelques années.

🥉 3. VRM CPU/RAM un peu faible

alimentation instable lors du power-down / power-up

surtout visible au reboot, pas en fonctionnement continu

5️⃣ Ce qui est peu probable

❌ CPU intrinsèquement défectueux
❌ Bug noyau
❌ Microcode AMD (aucun erratum connu dans ce sens)
❌ Surchauffe (ça ne se produit pas à l’extinction)

6️⃣ Diagnostic pragmatique (à l’ancienne, efficace)
Étape 1 — RAM (indispensable)

ouvrir la trappe

retirer la barrette

nettoyer contacts (air sec, pas de produit)

replacer fermement

si possible : changer la barrette

Une simple barrette DDR4 4 Go suffit pour trancher.

Étape 2 — BIOS

charger Setup Defaults

vérifier qu’il n’y a aucun mode “Fast Boot” exotique

si mise à jour BIOS possible, la faire

Étape 3 — Test simple

extinction complète (pas reboot)

attendre 30 s

redémarrage

Si :

extinction propre = OK

reboot = MCE

➡️ VRM ou RAM en limite, pas logiciel.

7️⃣ Solution réaliste

90 % des cas : remplacement RAM → problème réglé

reste : carte mère vieillissante → pas économiquement réparable

8️⃣ Conclusion nette

👉 Ce MCE n’est pas alarmant au sens “CPU mort”, mais
👉 il signale une instabilité matérielle réelle, déclenchée par les transitions d’alimentation.
👉 La RAM est la première coupable, suivie de près par l’alimentation mémoire.

Si tu veux, dis-moi :

quantité de RAM installée

1 ou 2 barrettes

âge approximatif de la machine

Je te dirai si ça vaut la peine d’investir 20 €… ou s’il faut passer à autre chose sans regret.

Bien sûr !
Le message que tu vois dans les logs (mce: [Hardware Error]) indique une erreur matérielle grave sur ton HP-15-db0xxx, plus précisément une Machine Check Exception (MCE). Voici ce que cela signifie et ce que tu peux faire :

Que signifie cette erreur ?

CPU 0 a détecté une erreur matérielle, avec le code 0x70f0f dans la banque 4.
Ce type d’erreur est souvent lié à :

Un problème de cache CPU (surtout le cache L3)
Un problème de mémoire RAM
Un problème de surchauffe ou d’alimentation
Un bug du BIOS ou du microcode (ton log montre "microcode 0", ce qui est inhabituel et peut indiquer un problème de rapport d’erreur)

Que faire immédiatement ?
1. Vérifier la surchauffe

Nettoie les ventilateurs et vérifie que le refroidissement fonctionne bien.
Utilise un outil comme lm-sensors (Linux) ou HWMonitor (Windows) pour surveiller les températures.
2. Tester la RAM

Lance un test mémoire (par exemple, MemTest86) pendant plusieurs heures pour écarter un problème de RAM.
3. Mettre à jour le BIOS et le microcode

Va sur le site de support HP et installe la dernière version du BIOS pour ton modèle.
4. Vérifier la stabilité du CPU

Si tu as overclocké ton processeur, rétablis les paramètres d’usine.
Fais un test de stress (par exemple, avec Prime95) pour voir si l’erreur réapparaît sous charge.
5. Consulter les logs système

Sous Linux, tape dmesg | grep -i mce pour voir s’il y a d’autres erreurs récentes.
Note si l’erreur survient à un moment précis (démarrage, sous charge, aléatoirement…).
6. Diagnostic matériel approfondi

Si le problème persiste, le processeur ou la carte mère peut être défectueux. Contacte le support HP si ton ordinateur est encore sous garantie.

As-tu remarqué d’autres symptômes ? (plantages, ralentissements, redémarrages intempestifs ?)
Ou veux-tu que je t’aide à analyser d’autres parties de tes logs ?

Merci pour l’extrait, il est suffisamment parlant.

Je vais l’analyser sobrement et factuellement, à la manière dont on traite ce genre de choses en exploitation sérieuse.

1️⃣ Ce que dit exactement ce MCE
CPU 0: Machine Check: 0
Bank 4: f60000000000070f
ADDR fdfcc000cfc
PROCESSOR 2:670f00
APIC 0 microcode 0

Points essentiels :

Bank 4

Status : f60000000000070f

Adresse physique valide

Erreur détectée très tôt au boot (~0,84 s)

Ce n’est pas anodin, et surtout pas logiciel.

2️⃣ Interprétation du registre STATUS (AMD)

Sur AMD, le champ STATUS se lit ainsi (schéma MCA classique) :

VAL = 1 → erreur valide

UC = 1 → uncorrected (non corrigeable)

EN = 1 → erreur signalée

ADDRV = 1 → adresse fautive valide

PCC = 1 → processor context corrupt

👉 Le processeur lui-même déclare que son état interne est corrompu.

Ce point est capital.

3️⃣ Signification de la Bank 4 sur AMD A-Series / Zen-like

Sur ces processeurs :

Bank 4 correspond au contrôleur mémoire / data fabric / L2

Très souvent :

accès mémoire fautif

corruption de ligne de cache

problème d’interface RAM ↔ CPU

👉 Ce n’est PAS un bug de microcode connu.
👉 Ce n’est PAS un problème de noyau Linux.

4️⃣ Le timing est révélateur

0.842736 s après le démarrage

Cela signifie :

erreur avant toute charge

avant drivers

avant gestion d’énergie avancée

avant surchauffe

➡️ Cause matérielle franche, pas marginale.

5️⃣ Causes les plus probables (par ordre réaliste)
🥇 1. RAM défectueuse ou instable

Très fréquent sur cette génération HP :

barrette fatiguée

slot oxydé

timing limite

tension mal tenue

Même une seule cellule défectueuse suffit.

🥈 2. Contrôleur mémoire du CPU dégradé

Sur les AMD A6/A9 :

IMC peu robuste

sensible à la température passée

vieillissement réel

👉 Dans ce cas, changer la RAM ne suffit pas toujours.

🥉 3. Carte mère / VRM instable

Plus rare mais connu sur des portables entrée de gamme :

alimentation CPU bruitée

chute de tension transitoire

condensateurs vieillissants

6️⃣ Ce que ce n’est pas

❌ Pas un bug Linux
❌ Pas un problème de microcode documenté
❌ Pas un souci de « compatibilité distro »
❌ Pas une erreur bénigne ignorable

Un PCC=1 n’est jamais bénin.

7️⃣ Ce que je ferais, dans l’ordre
Étape 1 — RAM

memtest86+ (plusieurs passes)

si possible :

tester une autre barrette

tester dans l’autre slot

Étape 2 — BIOS

vérifier version BIOS HP

remettre paramètres par défaut

désactiver toute option “performance” ou “boost”

Étape 3 — Verdict réaliste

Si le MCE :

apparaît toujours au boot

sur RAM différente

BIOS à jour

➡️ CPU ou carte mère en fin de vie

Sur ce modèle précis, cela arrive, surtout après plusieurs années.

8️⃣ Conclusion claire

👉 Oui, ce MCE est grave.
👉 Il indique une corruption matérielle non corrigeable.
👉 La RAM est la première suspecte, mais le contrôleur mémoire du CPU est très plausible.
👉 Aucun correctif logiciel ne réglera cela durablement.

Si tu veux, tu peux me donner :

résultat d’un memtest

ou la référence exacte du CPU (A6-9225 / A9-9425)

ou me dire si l’erreur est systématique ou intermittente

Je te dirai alors s’il vaut la peine d’insister… ou s’il faut être raisonnable et conclure.

HP-15-db0xxx

Le modèle HP 15-db0xxx est une série de laptops HP entrée/milieu de gamme sortie autour de 2018-2019, principalement équipée de processeurs AMD (et non Intel).
Configurations les plus courantes pour ce modèle

AMD Ryzen 3 2200U (le plus fréquent)
AMD Ryzen 5 2500U
AMD A9-9425 / A6-9225 (versions bas de gamme)
AMD Ryzen 3 ou 5 de la famille Raven Ridge (architecture Zen 1)

C'est un portable 15.6" classique (souvent écran HD 1366×768), avec 4 à 8 Go DDR4, HDD ou SSD, Radeon Vega graphics intégrés.
Problème majeur avec l'erreur MCE que tu as montrée
Le log que tu as partagé indique clairement un processeur Intel :

PROCESSOR 2:670f00 → c'est le CPUID signature d'un processeur AMD de la famille Stoney Ridge / Bristol Ridge (Zen 1 basse consommation)
Plus précisément : souvent AMD A9-9410, A6-9210, A6-9225, A9-9425, etc.
Le code 670F00 est bien AMD (Intel commence par 06xx ou plus récent comme 906Ex pour Alder Lake).

Bank 4 + status f60000000000070f0f → erreur non corrigée (UC) + fatale (PCC=1) dans le cache L2 ou L3 (typique sur ces puces AMD anciennes quand elles vieillissent)

Ton HP 15-db0xxx est donc très probablement équipé d'un AMD APU Stoney Ridge (ex. A9-9425 ou similaire), pas d'un Intel Alder/Raptor Lake comme je l'avais supposé initialement (désolé pour l'erreur, le CPUID est très clair une fois vérifié en profondeur).
Gravité de cette erreur sur ces AMD 2016-2019
Ces APU AMD (Zen 1 mobile bas de gamme) sont connus pour :

Dégradation progressive du cache interne après 4-7 ans d'utilisation intensive
Sensibilité à la chaleur (souvent mal ventilés dans les châssis HP 15 bon marché)
Erreurs MCE fatales quand le cache L2/L3 commence à lâcher → c'est souvent le début de la fin

Pronostic réaliste en 2026 :

Si c'est la première fois que tu vois cette erreur et que le PC reste stable depuis → tu as peut-être encore quelques mois (voire 6-18 mois) devant toi en étant prudent
Si ça réapparaît régulièrement (surtout sous charge : navigation + onglets, vidéo, etc.) → le CPU est en dégradation avancée → mort probable dans les 3-12 mois
Une fois que les erreurs MCE non corrigées apparaissent en bank 4 sur ces puces, le remplacement du CPU (soudé) est impossible → il faut changer le laptop entier

Que faire concrètement maintenant ?

Surveiller intensivement
Installe rasdaemon (ou mcelog si ton distro est ancienne) et regarde les logs tous les jours :Bash

Un test avec Grok, j'ai juste envoyé ta capture d'écran

Cette sortie montre un rapport de Machine Check Exception (MCE) — une alerte matérielle très sérieuse envoyée directement par le processeur.
Voici l'analyse ligne par ligne de ce que tu montres :

Interprétation la plus probable (2024–2026)

Information,Valeur,Signification la plus courante
Bank 4,—,Sur la plupart des processeurs Intel récents → cache L2 ou L3
Status = f60000000000070f0f,—,Erreur non corrigée (UC = Uncorrected) + erreur fatale
Bit UC = 1,(f6… = 1111 0110),Erreur non corrigée → le processeur n'a pas pu la réparer
Bit PCC = 1,(souvent dans f6xx),Processor Context Corrupt → très mauvais signe
Model spécifique,2:670f00,Famille 6 / Model 0x67 → Intel Alder Lake / Raptor Lake mobile (12e/13e génération H/P/U) ou dérivés récents

Verdict le plus réaliste en janvier 2026
Très probablement un processeur Intel 12e/13e génération mobile (ou dérivé) qui montre les premiers signes de dégradation du cache (très courant sur ces générations depuis fin 2023).

Si le PC est stable depuis plusieurs mois → tu peux continuer à l'utiliser avec surveillance renforcée
S'il commence à planter / geler / redémarrer → prépare-toi à le remplacer (RMA si encore sous garantie, sinon mort quasi certaine dans les 3–18 mois)

N'hésite pas à revenir avec :

Le modèle exact du processeur (lscpu ou cat /proc/cpuinfo)
Les logs rasdaemon après quelques jours
Si le PC plante ou pas

Bon courage ! 😓

Si les artistes sont français alors ils réalisent des spectacles, pas des "performances"

avec systemd, obtenir des infos:

systemctl status mongodb

obtenir le journal (chronologie inversée)

journalctl -r -u mongodb

Je boot en uefi sur clé USB avec kubuntu, avec un simple dd de l'ISO.

C'est bien connu des joueurs, et ça fonctionne partout.

Bon, sans leap file TAI == 0

6.14.1. NTP Versions 4.2.6 and newer
Copy the leap seconds file onto your system running ntpd and add a line to your ntp.conf:
leapfile "/path/to your/leap-file"
You need to restart ntpd to apply your configuration changes.

Du coup, si ma machine n'a pas accès au web, pas de mise à jour automatique. Il me reste plus qu'à parser les annonces Ptp qui elles contiennent cette valeur que le serveur PtP obtient par la diffusion GPS.

Merci, je teste ntp_gettimex() asap.
Le système n'est pas connecté au web, donc les données ietf à télécharger, j'oublie.

Merci encore.

Bonjour le fait, avahi est son implémentation avec nss-mdns pour la résolution de nom.

Perso, j'utilise KDEConnect

J'ignorais que l'homme en marche sentait si fort.

Bon vu la précision de datation, je peux augmenter le quantum date (1ns vers 1 us) et celui du compteur (1,6ns vers 1,6us). Du coup je passe à l'aise en double.

Pour information, j'encapsule de cette manière :

struct CairoSurfaceDeleter { void operator() ( cairo_surface_t *cs ) { cairo_surface_destroy( cs ); } };
std::unique_ptr<cairo_surface_t, CairoSurfaceDeleter> cairoSurface;

mais comme j'utilise c++11, j'aimerais bien utiliser une lambda pour le destructeur.
Si quelqu'un sait faire, je gagnerai un peu de temps.

Merci,

Je vais donc continuer à utiliser l'api C en gérant l'instance et la destruction à la main. Dans mon cas cairo fait bien le job.
Par contre, je fais ça avec des pointeurs nus, avec tous les pointeur C dans une classe private d-pointer, avec les deleter dans le destructeur de cette classe.
C'est pas tip top C++ mais ça fonctionne. Je vais regarder un peu si il y a une alternative pas trop chiante.

Merci en tout cas de partager ton expérience.

J'utilise pour ce genre de config l'ex crunchbang : bunsen.

C'est du debian avec du openbox, minimaliste mais assez facile à prendre en main.

Tu trouveras leur ISO là : BunsenLabs

Elles sont bien tes notes, mais rien de plus que https://wiki.gentoo.org/wiki/Systemd

à moins peut-être de les mettre en français sur linuxFR ?

Cela arrive lorsque il n'y a plus de place dans le home directory.

Si tu as le temps, donne nous un

df -h /home/*

Petite mise au point sur les teams impliquées :

Un simple lien pour t'aider à mettre les bons drapeaux à côté des jolis points: autant connaître les chefs de team.

http://maximechaix.info/?p=832

Et tu as essayé avec un numéro de port > 1024 ?
Car il me semble que pour utiliser un port privilégié il faut la capacité cap_net_bind_service.

Voilà, c'est exactement le paquet téléchargé.
Le dropbox est un dossier séparé, mais il faut que je fasse un rappel aux utilisateurs de ce qui doit ou ne doit pas être déposé dans ce dossier.
Dropbox est devenu petit à petit l'endroit pour partager entre utilisateurs tout et n'importe quoi (alors que ce devrait être que les sauvegardes pour la société).
Bon, j'espère que le noexec ne me créera pas de mauvais effets de bord.