- Détails
Dans le temps, j'ai connu les pannes de la Wii qui devait avoir son alimentation réinitialisée, mais là ma barre de son Razer Leviathan V2 a fait des siennes après une panne de courant ce matin...
J'ai vu avec déception que mon UPS est probablement mort ce matin quand une panne de courant a éteint mon ordinateur, alors que tous les autres appareils ondulés sont restés en vie... Le courant est revenu en moins de 5 minutes, et tout est reparti... Sauf ma barre de son. 🤔
Ni l'éteindre et la rallumer, ni la débrancher et la rebrancher n'ont suffi à la ramener. Elle s'allumait, mais Windows ne la reconnaissait pas, elle était détectable en Bluetooth mais elle décrochait aussitôt, elle était morte... 😒
De sortie aujourd'hui, j'ai laissé tout en l'état et j'ai repris mes investigations le soir. J'avais vu un post d'un mec qui disait de tout débrancher, et de connecter l'alimentation de la barre à une prise de courant, en direct. Ça me paraissait étonnant, mais au point où j'étais, j'ai tenté.
Et bizarrement, étonnamment, ça a marché. 🎉 J'ai aussi utilisé la combinaison power + boutons de volume en même temps qui est suspecté d'être un hard reset, je ne sais pas ce qui a été le plus efficace.
J'en ai profité pour mettre à jour le firmware et Synapse, dont la version 4 a été finalisée il y a peu.
J'avais aussi ouvert un ticket chez Razer, qui promettent une réponse sous 120 heures et qui a répondu en 8, pas trop mal. 👍 Inutile au final vu que j'ai résolu moi-même. 😅
- Détails
J'ai eu un bug bizarre sur ma Galaxy Watch 7. C'était le dimanche matin après passage à l'heure d'hiver, et je me suis rendu compte que l'heure affichée sur le cadran always on est différente de l'heure sur le cadran réel... On dirait que la montre entretient une horloge pour chacun des modes d'affichage, l'heure tourne sur chacune, mais restent décalées d'une heure. Elles ont fini par se resynchroniser, mais ça a duré peut-être quelques heures ?
- Détails
J'ai maintenant un Prodesk 600 G3 mini. Et comme tout bon geek, je l'ai upgradé à fond (ou presque). Mais ça a été plus folko que je pensais... 😅
J'ai acheté de la RAM, 8 Go. Je n'ai pas remplacé la RAM existante, elle marche bien, et c'est de la Hynix.
J'ai acheté un Core i5 7500T, vrai quad-core, basse consommation. Le Core i3 6100T d'origine est dual-core hyperthreading, mais avec fréquence plus élevée.
J'ai aussi trouvé un module HDMI pour remplacer le module série. C'est la partie la plus simple, juste enlever 2 vis, changer le module, revisser, fini, j'ai un port HDMI. 😉
La RAM, facile aussi, juste à clipser sur l'emplacement vide. Le processeur aussi, enlever le radiateur, enlever l'ancien processeur, mettre le nouveau, mettre de la pâte thermique, remettre le radiateur, terminé.
Ensuite, tester la RAM. Toujours tester la RAM. Et c'est le drame. La machine plante carrément sous Memtest86+... 😰 Je me rends compte que le 2e slot de RAM provoque immédiatement une erreur... La machine ne démarre même plus avec un module dedans, que ce soit celui d'origine ou le nouveau... Et les bips indiquent bien un problème de mémoire... 😑
Je me décide à commander une barrette de 16 Go. 😑 Et là, en relisant un post sur le net, je vois que quelqu'un a eu le même problème, et qu'en fait le socket était sale... Je démonte la machine, mon socket est nickel. Mais le processeur avait des contacts crados... 😥
Ni une ni deux j'essuie les contacts, je remonte tout, je remets les deux modules de RAM, et tout marche ! 🎉
Bon il faut tester la RAM quand même, et tout passe. 😉
Et pendant mes tribulations, j'ai decouvert un truc avec HP et Secure Boot... J'avais laissé Secure Boot activé, et j'avais fait des mises à jour Windows avec l'install qui est arrivée avec pour mettre à jour le BIOS. Et là en démarrant un Ventoy, je me prends une erreur Verifying shim SBAT data failed: Security Policy Violation
... C'est un problème connu, Microsoft a invalidé des clés Secure Boot, dont certaines utilisées par les Linux...
Bizarrement mon Debian qui démarrait bien jusque-là s'est aussi pris l'erreur... 😑 Je me suis dit que j'allais désactiver Secure Boot. Il y a un menu exprès dans le BIOS HP. Au redémarrage, le BIOS demande qu'on tape un code numérique affiché à l'écran, pour confirmer la désactivation. Mais je me rends compte que ça ne marche pas, le Secure Boot est réactivé tout seul... 😑
Après un moment à chercher, je découvre qu'en fait le code tapé doit s'afficher à l'écran... Je tapais les touches numériques tel quel en clavier US, mais j'avais dû le mettre en FR... 😑 En tapant les touches numériques avec Maj, les chiffres s'affichent et Secure Boot se désactive. 🎉
J'en ai profité pour mettre à jour les clés Secure Boot de mon Debian :
apt update
apt install --reinstall grub-efi-amd64-signed shim-signed
grub-install
update-grub
En retestant avec Secure Boot, ça passe. 😉 Je l'ai redésactivé dans le doute...
Et donc au final, qu'est-ce que ça m'a apporté ? Deux fois plus de RAM, toujours la même utilisation :
Graphe mémoire de Btop++
En ce qui concerne le processeur... J'ai trouvé quelques benchmarks sur le net, et c'est... édifiant. D'abord sysbench. Le test CPU calcule des nombres premiers pendant 10 secondes.
Résultat pour le Core i3 6100T :
# sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1061.90
General statistics:
total time: 10.0002s
total number of events: 10621
Latency (ms):
min: 0.94
avg: 0.94
max: 1.23
95th percentile: 0.94
sum: 9997.66
Threads fairness:
events (avg/stddev): 10621.0000/0.00
execution time (avg/stddev): 9.9977/0.00
Résultats pour le Core i5 7500T :
# sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1080.48
General statistics:
total time: 10.0003s
total number of events: 10807
Latency (ms):
min: 0.91
avg: 0.93
max: 1.36
95th percentile: 0.97
sum: 9997.99
Threads fairness:
events (avg/stddev): 10807.0000/0.00
execution time (avg/stddev): 9.9980/0.00
Le 6100T trouve 1062 nombres par seconde, contre 1080 pour le 7500T. J'ai donc gagné... 2 % de performances. Pour presque 45 €. 😅
Je teste Geekbench, et je me trouve rassuré. 🎉
Le test single core me donne 1181 pour le 6100T, pour 1239 pout le 7500T. 5 %. C'est "mieux". 😒
Mais le test multi-core est bien meilleur ! 2237 pour le 6100T, et 3686 pour le 7500T, 65 % d'amélioration ! 🎉 Mais bon, Btop++ me dit que c'est toujours inutile... 😅
Info CPU Btop++
Donc voilà, je suis passé à côté d'acheter de la RAM pour rien, d'avoir une machine qui plante aléatoirement, pour au final dépenser autant sur les pièces inutiles que la machine entière. Trop bien. 🤣