[Microcode intel]Compatible? PK dois je l'installer?(Résolu)

[Backtoback]

Bonjour,

J'ai lu pas mal de choses sur le microcode, mais je n'ai pas bien compris à quoi il servait.
https://wiki.archlinux.org/index.php/Mi ... de_Updates

Je ne sais pas vraiment si je suis compatible aussi :

*-cpu
description: CPU
produit: Core i7 (Fill By OEM)
fabriquant: Intel Corp.
identifiant matériel: 14
information bus: cpu@0
version: Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz
emplacement: SOCKET 0
taille: 2GHz
capacité: 3800MHz
bits: 64 bits
horloge: 100MHz
fonctionnalités: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt cpufreq
configuration: cores=4 enabledcores=4 threads=8
*-cache:0
description: L2 cache
identifiant matériel: 15
emplacement: CPU Internal L2
taille: 1MiB
capacité: 1MiB
fonctionnalités: internal write-back unified
*-cache:1
description: L1 cache
identifiant matériel: 16
emplacement: CPU Internal L1
taille: 256KiB
capacité: 256KiB
fonctionnalités: internal write-back
*-cache:2
description: L3 cache
identifiant matériel: 17
emplacement: CPU Internal L3
taille: 6MiB
capacité: 6MiB
fonctionnalités: internal write-back unified
*-memory
description: Mémoire Système
identifiant matériel: 18
emplacement: Carte mère
taille: 8GiB
*-bank:0
description: SODIMM DDR3 Synchrone 1600 MHz (0,6 ns)
produit: F3-1600C11-4GSL
fabriquant: Fujitsu
identifiant matériel: 0
numéro de série: 00000000
emplacement: ChannelA-DIMM0
taille: 4GiB
bits: 64 bits
horloge: 1600MHz (0.6ns)
*-bank:1
description: DIMMProject-Id-Version: @(#) $Id: fr.po 2151 2010-03-15 20:26:20Z lyonel $Report-Msgid-Bugs-To: POT-Creation-Date: 2009-10-08 14:02+0200PO-Revision-Date: 2009-10-08 14:06+0100Last-Translator: Lyonel Vincent <lyonel@ezix.org>Language-Team: MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit [vide]
produit: [Empty]
fabriquant: [Empty]
identifiant matériel: 1
numéro de série: [Empty]
emplacement: ChannelA-DIMM1
*-bank:2
description: SODIMM DDR3 Synchrone 1600 MHz (0,6 ns)
produit: F3-1600C11-4GSL
fabriquant: Fujitsu
identifiant matériel: 2
numéro de série: 00000000
emplacement: ChannelB-DIMM0
taille: 4GiB
bits: 64 bits
horloge: 1600MHz (0.6ns)
*-bank:3
description: DIMMProject-Id-Version: @(#) $Id: fr.po 2151 2010-03-15 20:26:20Z lyonel $Report-Msgid-Bugs-To: POT-Creation-Date: 2009-10-08 14:02+0200PO-Revision-Date: 2009-10-08 14:06+0100Last-Translator: Lyonel Vincent <lyonel@ezix.org>Language-Team: MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit [vide]
produit: [Empty]
fabriquant: [Empty]
identifiant matériel: 3
numéro de série: [Empty]
emplacement: ChannelB-DIMM1

Je suppose qu'il permet d'avoir les derniers versions fournit par intel non?

Merci pour vos éclaircissements

B2B

[raymondcal]

Je me pose exactement la même question…
J’ai un PC portable avec un Intel Celeron, visiblement compatible avec le microcode, mais je n’ai jamais eu le paquet intel-ucode et tout marche pourtant parfaitement bien.
Je sais bien que la devise de l’informaticien consciencieux, c’est de ne pas réparer ce qui n’est pas cassé, mais la vie est trop courte, c’est pour ça que je suis Archlinux.
Donc si je l’installe, est-ce que tout va marcher mieux ? Est-ce que ça attirer les filles ?
Ou est-ce que je continue comme avant, sans microcode ?

[Backtoback]

Je me suis dit que je devais pas etre le seul à me poser la question de son utilité

[FoolEcho]

Je pense y avoir répondu sur ce message: post136572.html#p136572 .

Par contre, je veux bien une explication sur l'utilité su sus-cité paquet.

En complément, le paquet et la modification servent à mettre à jour le microcode des CPUs au démarrage de la machine.
C'est comparable à une mise à jour du BIOS, sauf que la procédure n'est pas pérenne (étant logicielle, elle sera faite à chaque démarrage ce qui peut sembler moins intéressant, sauf qu'une mise à jour directe du BIOS est susceptible de casser la machine si elle se passe mal... ).

Pour info, avant modification, ça peut donner quelque chose comme:

Code : Tout sélectionner

$ dmesg|grep microcode
[    6.396919] microcode: CPU0 sig=0x106e5, pf=0x2, revision=0x3
[    6.653714] microcode: CPU1 sig=0x106e5, pf=0x2, revision=0x3
[    6.653781] microcode: CPU2 sig=0x106e5, pf=0x2, revision=0x3
[    6.653830] microcode: CPU3 sig=0x106e5, pf=0x2, revision=0x3
[    6.653853] microcode: CPU4 sig=0x106e5, pf=0x2, revision=0x3
[    6.653867] microcode: CPU5 sig=0x106e5, pf=0x2, revision=0x3
[    6.653893] microcode: CPU6 sig=0x106e5, pf=0x2, revision=0x3
[    6.653932] microcode: CPU7 sig=0x106e5, pf=0x2, revision=0x3
[    6.653993] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

et après (si ça se passe bien ):

Code : Tout sélectionner

$ dmesg|grep microcode
[    0.000000] CPU0 microcode updated early to revision 0x7, date = 2013-08-20
[    0.210244] CPU1 microcode updated early to revision 0x7, date = 2013-08-20                                 
[    0.230191] CPU2 microcode updated early to revision 0x7, date = 2013-08-20                                 
[    0.248460] CPU3 microcode updated early to revision 0x7, date = 2013-08-20                                 
[    0.629027] microcode: CPU0 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629033] microcode: CPU1 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629039] microcode: CPU2 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629044] microcode: CPU3 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629050] microcode: CPU4 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629056] microcode: CPU5 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629061] microcode: CPU6 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629065] microcode: CPU7 sig=0x106e5, pf=0x2, revision=0x7                                               
[    0.629101] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba 

L'avantage étant qu'il suffit d'éditer les options au démarrage si on souhaite s'en passer (ou en cas de problème).

Procéder ainsi permet donc de ne pas avoir besoin de passer par une mise à niveau de son BIOS (qui n'est pas une opération triviale comme je disais) tout en bénéficiant du même effet.

[Backtoback]

Merci pour cette réponse, elle m'avait échappé.

Cependant, qu'apporte des mises à jours BIOS?

L'avantage est que si la MAJ BIOS nous embête pour X raisons, on peut simplement revenir en arrière en remodifiant le fichier de conf pour revenir à l'ancien BIOS.

[FoolEcho]

L'avantage est que si la MAJ BIOS nous embête pour X raisons, on peut simplement revenir en arrière en remodifiant le fichier de conf pour revenir à l'ancien BIOS.

Attention, ce que j'ai dit et l'annonce ne concernent pas une mise à jour du bios, mais des composants comme le CPU intel ici (seulement si on veut mettre effectivement à jour le microcode des composants de façon pérenne, ça passe par une mise à jour du bios).

Cependant, qu'apporte des mises à jours BIOS?

D'apporter des corrections au microcode des différents composants (version du bios, carte mère -- ce qui n'est pas sans risque --, processeur, reconnsaissance du matériel, etc.). Comme ça touche directement aux entrées/sorties de la machine, ça peut avoir plus ou moins d'impact visible (très souvent, ça se voit parce qu'on va par exemple le mettre à jour en cas de difficulté de reconnaissance d'un composant récent, les CPUs peuvent aussi y gagner en efficacité ce qui se ressent sur l'utilisation d'un système d'exploitation, etc. ; l'impact le plus spectaculaire étant une mise à jour foirée de la carte mère où vous êtes bon pour un retour chez le fabricant). Passer par les mises à jour logicielles comme intel-ucode + kernel pour le CPU intel permet de bénéficier de ce type de mise à jour sans risque.

[-redhead-]

Bonjour,

Donc, en gros, si on a un bios à jour, cette modif n'est pas nécessaire ?

[FoolEcho]

Donc, en gros, si on a un bios à jour, cette modif n'est pas nécessaire ?

C'est superflu dans ce cas oui, car la mise à jour du bios doit s'accompagner de celles des composants (mais encore une fois: la question du intel-ucode ne met à jour «que» le microcode du CPU intel, il n'est pas question du bios)... après quand on ne surveille pas forcément ces aspects de mise à jour matérielle, c'est pas mal non plus...

(l'annonce a au moins eu le mérite de mettre en avant ces questions, mais oui, si vous avez bien vécu jusque là sans ces histoires, vous pouvez parfaitement continuer sans... ^^)

[Xorg]

Bonjour,

Donc, en gros, si on a un bios à jour, cette modif n'est pas nécessaire ?

Il faut voir si ton CPU utilise le même microcode quand tu utilises un BIOS à jour seul et un BIOS à jour + intel-ucode,et là tu sauras si ce paquet est utile.
Cela dit, je ne sais pas si les fabricants de cartes-mères proposent systématiquement une nouvelle mise à jour du BIOS en cas de nouvelle version du microcode.

EDIT : J'ai le dernier BIOS disponible pour ma carte-mère, et sans intel-ucode la revision de mon processeur est la 0x28, alors qu'avec c'est la 0x29.
Donc pour la faire courte, si, avoir ce paquet même si on a un BIOS "à jour" peut être nécessaire.

[waitnsea]

Quant à mettre son Bios à jour, ça reste une opération à risque.
Asus a un outil qui rend l'opération apparemment facile, je l'ai donc fait 2 fois "finger in the nose", mais... planté la 3° et, là je ne dis pas où on peut se mettre le doigt ! Il ne m'est plus resté qu'à faire re-flasher la ROM

[Xorg]

Quant à mettre son Bios à jour, ça reste une opération à risque.
Asus a un outil qui rend l'opération apparemment facile, je l'ai donc fait 2 fois "finger in the nose", mais... planté la 3° et, là je ne dis pas où on peut se mettre le doigt ! Il ne m'est plus resté qu'à faire re-flasher la ROM

Tu n'as peut-être pas de chance alors. Pour avoir déjà flashé des multiples fois des BIOS, plusieurs fabricants différents (dont un assez casse-pieds comme Dell), ça n'a jamais planté.
Même en flashant plusieurs fois le BIOS de ma carte-graphique pour l'overclocker ça n'a pas raté, et pourtant il fallait utiliser atiflash sous DOS pour ça.

Comme ton pseudo le dit si bien, lors d'une mise à jour de BIOS, wait and see, mais je déconseille de toucher la machine avant que l'opération soit terminée.

[waitnsea]

Là on est en plein HS...
Je pense que c'était du à un support défectueux.

[Backtoback]

Perso j'ai fait l'install, j'ai pas vraiment vu de changement mais tout semble s'être bien passé
Dois je mettre résolu, ou comme c'est une question ouverte je laisse le topic continuer?

[Xorg]

Là on est en plein HS...

Oui, désolé.

Perso j'ai fait l'install, j'ai pas vraiment vu de changement mais tout semble s'être bien passé
Dois je mettre résolu, ou comme c'est une question ouverte je laisse le topic continuer?

Tu peux le mettre en résolu je pense.
"Normal" que tu ne vois pas de changements, ça concerne que certaines instructions, et il faudra utiliser les instructions en questions. Par exemple, les processeurs Haswell d'Intel ont un bug avec l'instruction TSX, et une mise à jour du microcode permet de désactiver cette instruction. Bref, c'est sûr que ce n'est pas l'utilisateur lambda qui se sentira concerné, mais je pense qu'il est bien d'avoir un microcode à jour.

[Backtoback]

Merci à tous pour vos réponses et éclaircissements