x86, intel: Output microcode revision v2
Subsystems (3)
PATCH 1/3 x86, intel: Output microcode revision v2
From: Andi Kleen <[email protected]>
I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo, which I added at the end to minimize impact on parsers.
The update level is also outputed on fatal machine checks together with the other CPUID model information.
I removed the respective code from the microcode update driver, it just reads the field from cpu_data. Also when the microcode is updated it fills in the new values too.
I had to add a memory barrier to native_cpuid to prevent it being optimized away when the result is not used.
This turns out to clean up further code which already got this information manually. This is done in followon patches.
v2: Lots of updates based on feedback.
--- arch/x86/include/asm/processor.h | 5 ++++- arch/x86/kernel/cpu/intel.c | 14 ++++++++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 5 +++-- arch/x86/kernel/cpu/proc.c | 3 ++- arch/x86/kernel/microcode_intel.c | 14 +++++--------- 5 files changed, 28 insertions(+), 13 deletions(-)
arch/x86/include/asm/processor.h +4 -1
@@ -111,6 +111,8 @@ struct cpuinfo_x86 {/* Index into per_cpu list: */ u16 cpu_index;#endif +/* CPU update signature */ +u32 cpu_update; } __attribute__((__aligned__(SMP_CACHE_BYTES)));#define X86_VENDOR_INTEL 0
@@ -179,7 +181,8 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx, "=b" (*ebx), "=c" (*ecx), "=d" (*edx) - : "0" (*eax), "2" (*ecx)); + : "0" (*eax), "2" (*ecx) + : "memory"); }static inline void load_cr3 (pgd_t *pgdir)
arch/x86/kernel/cpu/intel.c +14 -0
@@ -364,6 +364,20 @@ static void __cpuinit init_intel(struct cpuinfo_x86 *c)early_init_intel (c); +/* Determine CPU update level */ +if (c->x86 >=6 && !cpu_has (c,X86_FEATURE_IA64 )) { +unsigned lower_word; + +wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); +/* The CPUID 1 fills in the MSR as documented in the SDM */ +/* +* Wrong comment from microcode_intel.c: +* see notes above for revision 1.07. Apparent chip bug +*/ +cpuid_eax (1 ); +rdmsr (MSR_IA32_UCODE_REV , lower_word, c->cpu_update); + } +intel_workarounds (c);/*
arch/x86/kernel/cpu/mcheck/mce.c +3 -2
@@ -220,8 +220,9 @@ static void print_mce(struct mce *m)pr_cont ("MISC %llx " , m->misc);pr_cont ("\n" ); -pr_emerg (HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x\n" , - m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid); +pr_emerg (HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x CPU-UPDATE %u\n" , + m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid, +cpu_data (m->extcpu).cpu_update);/* * Print out human-readable details about the MCE error,
arch/x86/kernel/cpu/proc.c +2 -1
@@ -85,6 +85,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m,"stepping\t: %d\n" , c->x86_mask); else seq_printf(m, "stepping\t: unknown\n"); +if (c->cpu_update) +seq_printf (m,"cpu update\t: %u\n" , c->cpu_update);if (cpu_has (c,X86_FEATURE_TSC )) {unsigned int freq =cpufreq_quick_get (cpu);
@@ -132,7 +134,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m," [%d]" , i); } } -seq_printf (m,"\n\n" );return 0 ;
arch/x86/kernel/microcode_intel.c +5 -9
@@ -161,12 +161,7 @@ static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) csig->pf =1 << ((val[1 ] >>18 ) &7 ); } -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -/* see notes above for revision 1.07. Apparent chip bug */ -sync_core (); -/* get the current revision from MSR 0x8B */ -rdmsr (MSR_IA32_UCODE_REV , val[0 ], csig->rev); - + csig->rev = c->cpu_update;pr_info ("CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n" , cpu_num, csig->sig, csig->pf, csig->rev);
@@ -299,9 +294,9 @@ static int apply_microcode(int cpu)struct microcode_intel *mc_intel;struct ucode_cpu_info *uci;unsigned int val[2 ]; -int cpu_num; +int cpu_num =raw_smp_processor_id (); +struct cpuinfo_x86 *c = &cpu_data (cpu_num); - cpu_num =raw_smp_processor_id (); uci = ucode_cpu_info + cpu; mc_intel = uci->mc;
@@ -317,7 +312,7 @@ static int apply_microcode(int cpu) (unsigned long) mc_intel->bits >> 16 >> 16);wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -/* see notes above for revision 1.07. Apparent chip bug */ +/* As documented in the SDM: Do a CPUID 1 here */ sync_core ();/* get the current revision from MSR 0x8B */
@@ -335,6 +330,7 @@ static int apply_microcode(int cpu) (mc_intel->hdr.date >> 16) & 0xff); uci->cpu_sig.rev = val[1 ]; + c->cpu_update = val[1 ];return 0 ; }
Signature · 1 line
1.7.4.4
PATCH 2/3 x86, intel: Use cpu_update for Atom errata check
From: Andi Kleen <[email protected]>
Now that the cpu update level is available the Atom PSE errata check can use it directly without reading the MSR again.
--- arch/x86/kernel/cpu/intel.c | 15 ++++----------- 1 files changed, 4 insertions(+), 11 deletions(-)
arch/x86/kernel/cpu/intel.c +4 -11
@@ -55,17 +55,10 @@ static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)* need the microcode to have already been loaded... so if it is * not, recommend a BIOS update and disable large pages. */ -if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 ) { -u32 ucode, junk; - -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -sync_core (); -rdmsr (MSR_IA32_UCODE_REV , junk, ucode); - -if (ucode <0x20e ) { -printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" ); -clear_cpu_cap (c,X86_FEATURE_PSE ); - } +if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 && + c->cpu_update <0x20e ) { +printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" ); +clear_cpu_cap (c,X86_FEATURE_PSE ); }#ifdef CONFIG_X86_64
Signature · 1 line
1.7.4.4
Re: [PATCH 2/3] x86, intel: Use cpu_update for Atom errata check
Quoted 6 lines · Andi Kleen
From: Andi Kleen <[email protected]>
Now that the cpu update level is available the Atom PSE errata check can use it directly without reading the MSR again.
Signed-off-by Andi Kleen <[email protected]>
Quoted 30 lines
--- arch/x86/kernel/cpu/intel.c | 15 ++++----------- 1 files changed, 4 insertions(+), 11 deletions(-)arch/x86/kernel/cpu/intel.c +4
-11@@ -55,17 +55,10 @@ static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)* need the microcode to have already been loaded... so if it is * not, recommend a BIOS update and disable large pages. */ -if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 ) { -u32 ucode, junk; - -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -sync_core (); -rdmsr (MSR_IA32_UCODE_REV , junk, ucode); - -if (ucode <0x20e ) { -printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" ); -clear_cpu_cap (c,X86_FEATURE_PSE ); - } +if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 && + c->cpu_update <0x20e ) { +printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" ); +clear_cpu_cap (c,X86_FEATURE_PSE ); }#ifdef CONFIG_X86_64
Signature · 1 line
Jean Delvare
PATCH 3/3 coretemp: Get microcode revision from cpu_data v2
In reply to Andi KleenFrom: Andi Kleen <[email protected]>
Now that the ucode revision is available in cpu_data remove the existing code in coretemp.c to query it manually. Read the ucode revision from cpu_data instead
v2: Fix misplaced variable init. Remove unused variables.
--- drivers/hwmon/coretemp.c | 31 +++++-------------------------- 1 files changed, 5 insertions(+), 26 deletions(-)
drivers/hwmon/coretemp.c +5 -26
@@ -324,15 +324,6 @@ static int get_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev) } } -static void __devinit get_ucode_rev_on_cpu (void *edx) -{ -u32 eax; - -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -sync_core (); -rdmsr (MSR_IA32_UCODE_REV , eax, *(u32 *)edx); -} -static int get_pkg_tjmax (unsigned int cpu,struct device *dev) {int err;
@@ -425,29 +416,17 @@ static void update_ttarget(__u8 cpu_model, struct temp_data *tdata,static int chk_ucode_version (struct platform_device *pdev) {struct cpuinfo_x86 *c = &cpu_data (pdev->id); -int err; -u32 edx;/* * Check if we have problem with errata AE18 of Core processors: * Readings might stop update when processor visited too deep sleep, * fixed for stepping D0 (6EC). */ -if (c->x86_model ==0xe && c->x86_mask <0xc ) { -/* check for microcode update */ - err =smp_call_function_single (pdev->id, get_ucode_rev_on_cpu, - &edx,1 ); -if (err) { -dev_err (&pdev->dev, -"Cannot determine microcode revision of " -"CPU#%u (%d)!\n" , pdev->id, err); -return -ENODEV ; - }else if (edx <0x39 ) { -dev_err (&pdev->dev, -"Errata AE18 not fixed, update BIOS or " -"microcode of the CPU!\n" ); -return -ENODEV ; - } +if (c->x86_model ==0xe && c->x86_mask <0xc && c->cpu_update <0x39 ) { +dev_err (&pdev->dev, +"Errata AE18 not fixed, update BIOS or " +"microcode of the CPU!\n" ); +return -ENODEV ; }return 0 ; }
Signature · 1 line
1.7.4.4
Re: [PATCH 3/3] coretemp: Get microcode revision from cpu_data v2
Hi Andi,
Quoted 5 lines · Andi Kleen
From: Andi Kleen <[email protected]>
Now that the ucode revision is available in
cpu_dataremove the existing code incoretemp.cto query it manually. Read the ucode revision fromcpu_datainstead
Where is this available? Not upstream yet, apparently. I get a build failure here.
Quoted 36 lines
v2: Fix misplaced variable init. Remove unused variables.
Signed-off-by Andi Kleen <[email protected]>--- drivers/hwmon/coretemp.c | 31 +++++-------------------------- 1 files changed, 5 insertions(+), 26 deletions(-)drivers/hwmon/coretemp.c +0
-11@@ -324,15 +324,6 @@ static int get_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev) } } -static void __devinit get_ucode_rev_on_cpu (void *edx) -{ -u32 eax; - -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -sync_core (); -rdmsr (MSR_IA32_UCODE_REV , eax, *(u32 *)edx); -} -static int get_pkg_tjmax (unsigned int cpu,struct device *dev) {int err;@@ -425,29 +416,17 @@ static void update_ttarget(__u8 cpu_model, struct temp_data *tdata,static int chk_ucode_version (struct platform_device *pdev) {struct cpuinfo_x86 *c = &cpu_data (pdev->id); -int err; -u32 edx;
drivers/hwmon/coretemp.c static void update_ttarget(__u8 cpu_model, struct temp_data *tdata, · line 439
Quoted 10 lines
drivers/hwmon/coretemp.c +0
-4/* * Check if we have problem with errata AE18 of Core processors: * Readings might stop update when processor visited too deep sleep, * fixed for stepping D0 (6EC). */ -if (c->x86_model ==0xe && c->x86_mask <0xc ) { -/* check for microcode update */ - err =smp_call_function_single (pdev->id, get_ucode_rev_on_cpu, - &edx,1 );
As a side note, this is fixing a section mismatch, as get_ucode_rev_on_cpu() was declared __devinit but chk_ucode_version() isn't. Thankfully this doesn't affect previous kernels. As far as I can see, chk_ucode_version could be made __devinit. I'll send a patch.
Quoted 9 lines
drivers/hwmon/coretemp.c +0
-9-if (err) { -dev_err (&pdev->dev, -"Cannot determine microcode revision of " -"CPU#%u (%d)!\n" , pdev->id, err); -return -ENODEV ; - }else if (edx <0x39 ) { -dev_err (&pdev->dev, -"Errata AE18 not fixed, update BIOS or " -"microcode of the CPU!\n" );
drivers/hwmon/coretemp.c static void update_ttarget(__u8 cpu_model, struct temp_data *tdata, · line 432
Quoted 10 lines
drivers/hwmon/coretemp.c +5
-2-return -ENODEV ; - } +if (c->x86_model ==0xe && c->x86_mask <0xc && c->cpu_update <0x39 ) { +dev_err (&pdev->dev, +"Errata AE18 not fixed, update BIOS or " +"microcode of the CPU!\n" ); +return -ENODEV ; }return 0 ; }
This all looks reasonable, but I am not able to test it.
Signature · 1 line
Jean Delvare
RE: [PATCH 3/3] coretemp: Get microcode revision from cpu_data v2
Quoted 12 lines
-----Original Message-----
From: Jean Delvare [mailto:[email protected]]
Sent: Wednesday, May 25, 2011 1:54 PM
To: Andi Kleen
Cc: [email protected]; [email protected]; Andi Kleen; [email protected]; Yu, Fenghua
Subject: Re: [PATCH 3/3] coretemp: Get microcode revision fromcpu_datav2Hi Andi,
On Wed, 25 May 2011 12:32:28 -0700, Andi Kleen wrote:
Quoted 9 lines
Quoted 5 lines
From: Andi Kleen <[email protected]>
Now that the ucode revision is available in
cpu_dataremove the existing code incoretemp.cto query it manually. Read the ucode revision fromcpu_datainsteadWhere is this available? Not upstream yet, apparently. I get a build failure here.
This is one of three patches. Cpu_data is defined in the first patch. You need to get the other two to test them.
But I think Andi will send out a newer version with some changes. So we can test the newer patch set then.
Thanks.
-Fenghua
Jean Delvare
Acked-byRe: [PATCH 3/3] coretemp: Get microcode revision from cpu_data v2
Quoted 18 lines · Fenghua
Quoted 18 lines
-----Original Message-----
From: Jean Delvare [mailto:[email protected]]
Sent: Wednesday, May 25, 2011 1:54 PM
To: Andi Kleen
Cc: [email protected]; [email protected]; Andi Kleen; [email protected]; Yu, Fenghua
Subject: Re: [PATCH 3/3] coretemp: Get microcode revision fromcpu_datav2Hi Andi,
Quoted 5 lines · Andi Kleen
From: Andi Kleen <[email protected]>
Now that the ucode revision is available in
cpu_dataremove the existing code incoretemp.cto query it manually. Read the ucode revision fromcpu_datainstead
Quoted 5 lines
Quoted 3 lines
Where is this available? Not upstream yet, apparently. I get a build failure here.
This is one of three patches.
Cpu_datais defined in the first patch. You need to get the other two to test them.
OK, thanks. This is (build-)tested now.
Andi, do you plan to merge this in 2.6.40 or later?
Signature · 1 line
Jean Delvare
Quoted 20 lines · Andi Kleen
From: Andi Kleen <[email protected]>
I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to
/proc/cpuinfo, which I added at the end to minimize impact on parsers.The update level is also outputed on fatal machine checks together with the other CPUID model information.
I removed the respective code from the microcode update driver, it just reads the field from
cpu_data. Also when the microcode is updated it fills in the new values too.I had to add a memory barrier to
native_cpuidto prevent it being optimized away when the result is not used.This turns out to clean up further code which already got this information manually. This is done in followon patches.
v2: Lots of updates based on feedback.
Quoted 8 lines
Signed-off-by Andi Kleen <[email protected]>--- arch/x86/include/asm/processor.h | 5 ++++- arch/x86/kernel/cpu/intel.c | 14 ++++++++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 5 +++-- arch/x86/kernel/cpu/proc.c | 3 ++- arch/x86/kernel/microcode_intel.c | 14 +++++--------- 5 files changed, 28 insertions(+), 13 deletions(-)
You ignored the majority of the review suggestions i gave you in the previous thread, and you know that i won't apply your patches without you addressing all feedback.
So why did you send this incomplete series?
Thanks,
Ingo
Quoted 3 lines
You ignored the majority of the review suggestions i gave you in the previous thread, and you know that i won't apply your patches without you addressing all feedback.
Huh? I addressed all suggestions that I didn't explicitely reject (which were few)
At least to my knowledge. If I missed something that I didn't reject please point it out.
Thanks.
-Andi
Andi,
Quoted 9 lines · Andi Kleen
Quoted 3 lines
You ignored the majority of the review suggestions i gave you in the previous thread, and you know that i won't apply your patches without you addressing all feedback.
Huh? I addressed all suggestions that I didn't explicitely reject (which were few)
At least to my knowledge. If I missed something that I didn't reject please point it out.
Ingo has politely asked you to change the patches and he gave very detailed advise. Now he pointed out that you ignored most of it.
So instead of sitting down and rereading the thread you want Ingo to do your homework and repeat what he already told you ?
You seem to believe that requests from maintainers are just random noise, which you can decide to reject or ignore depending on your personal preference. There is no such concept neither for you nor for anybody else.
Thanks,
tglx
Quoted 2 lines · Andi Kleen
From: Andi Kleen<[email protected]>
[...]
Quoted 4 lines
I had to add a memory barrier to
native_cpuidto prevent it being optimized away when the result is not used.
[...]
Quoted 9 lines
arch/x86/include/asm/processor.h +2
-1@@ -179,7 +181,8 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx, "=b" (*ebx), "=c" (*ecx), "=d" (*edx) - : "0" (*eax), "2" (*ecx)); + : "0" (*eax), "2" (*ecx) + : "memory"); }
[...]
arch/x86/kernel/cpu/intel.c static void __cpuinit init_intel(struct cpuinfo_x86 *c) · line 377
Quoted 1 line
arch/x86/kernel/cpu/intel.c +1
-0+cpuid_eax (1 );
I'm confused. Doesn't "asm volatile" (in native_cpuid) mean "don't optimize me out"?
I can't reproduce the disappearance of the cpuid instruction when I copied and pasted all the macros.
--Andy
Hi Andi,
Quoted 13 lines · Andi Kleen
From: Andi Kleen <[email protected]>
I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to
/proc/cpuinfo, which I added at the end to minimize impact on parsers.The update level is also outputed on fatal machine checks together with the other CPUID model information.
I removed the respective code from the microcode update driver, it just reads the field from
cpu_data. Also when the microcode is updated it fills in the new values too.
Quoted 7 lines
I had to add a memory barrier to
native_cpuidto prevent it being optimized away when the result is not used.This turns out to clean up further code which already got this information manually. This is done in followon patches.
v2: Lots of updates based on feedback.
Please run scripts/checkpatch.pl on your patches before your post them. This one adds trailing white space on 3 lines and leading spaces on 3 lines as well. Please fix.
Quoted 40 lines
Signed-off-by Andi Kleen <[email protected]>--- arch/x86/include/asm/processor.h | 5 ++++- arch/x86/kernel/cpu/intel.c | 14 ++++++++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 5 +++-- arch/x86/kernel/cpu/proc.c | 3 ++- arch/x86/kernel/microcode_intel.c | 14 +++++--------- 5 files changed, 28 insertions(+), 13 deletions(-)arch/x86/include/asm/processor.h +4
-1@@ -111,6 +111,8 @@ struct cpuinfo_x86 {/* Index into per_cpu list: */ u16 cpu_index;#endif +/* CPU update signature */ +u32 cpu_update; } __attribute__((__aligned__(SMP_CACHE_BYTES)));#define X86_VENDOR_INTEL 0@@ -179,7 +181,8 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx, "=b" (*ebx), "=c" (*ecx), "=d" (*edx) - : "0" (*eax), "2" (*ecx)); + : "0" (*eax), "2" (*ecx) + : "memory"); }static inline void load_cr3 (pgd_t *pgdir)arch/x86/kernel/cpu/intel.c +0
-0@@ -364,6 +364,20 @@ static void __cpuinit init_intel(struct cpuinfo_x86 *c)early_init_intel (c);
arch/x86/kernel/cpu/intel.c static void __cpuinit init_intel(struct cpuinfo_x86 *c) · line 376
Quoted 10 lines
arch/x86/kernel/cpu/intel.c +10
-0+/* Determine CPU update level */ +if (c->x86 >=6 && !cpu_has (c,X86_FEATURE_IA64 )) { +unsigned lower_word; + +wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); +/* The CPUID 1 fills in the MSR as documented in the SDM */ +/* +* Wrong comment from microcode_intel.c: +* see notes above for revision 1.07. Apparent chip bug +*/
Why copy this comment if it is wrong? Plus "above" is meaningless now that you moved it. If anyone really needs the info, it's in the git history forever, no need to pollute the source code.
Quoted 37 lines
arch/x86/kernel/cpu/intel.c +4
-0+cpuid_eax (1 ); +rdmsr (MSR_IA32_UCODE_REV , lower_word, c->cpu_update); + } +intel_workarounds (c);/* arch/x86/kernel/cpu/mcheck/mce.c +3
-2@@ -220,8 +220,9 @@ static void print_mce(struct mce *m)pr_cont ("MISC %llx " , m->misc);pr_cont ("\n" ); -pr_emerg (HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x\n" , - m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid); +pr_emerg (HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x CPU-UPDATE %u\n" , + m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid, +cpu_data (m->extcpu).cpu_update);/* * Print out human-readable details about the MCE error, arch/x86/kernel/cpu/proc.c +2
-0@@ -85,6 +85,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m,"stepping\t: %d\n" , c->x86_mask); else seq_printf(m, "stepping\t: unknown\n"); +if (c->cpu_update) +seq_printf (m,"cpu update\t: %u\n" , c->cpu_update);if (cpu_has (c,X86_FEATURE_TSC )) {unsigned int freq =cpufreq_quick_get (cpu);
arch/x86/kernel/cpu/proc.c static int show_cpuinfo(struct seq_file *m, void *v) · line 139
Quoted 7 lines
arch/x86/kernel/cpu/proc.c +0
-1@@ -132,7 +134,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m," [%d]" , i); } } -seq_printf (m,"\n\n" );return 0 ;
Please don't mix white space changes with real code changes.
Quoted 47 lines
arch/x86/kernel/microcode_intel.c +5
-9@@ -161,12 +161,7 @@ static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) csig->pf =1 << ((val[1 ] >>18 ) &7 ); } -wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -/* see notes above for revision 1.07. Apparent chip bug */ -sync_core (); -/* get the current revision from MSR 0x8B */ -rdmsr (MSR_IA32_UCODE_REV , val[0 ], csig->rev); - + csig->rev = c->cpu_update;pr_info ("CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n" , cpu_num, csig->sig, csig->pf, csig->rev);@@ -299,9 +294,9 @@ static int apply_microcode(int cpu)struct microcode_intel *mc_intel;struct ucode_cpu_info *uci;unsigned int val[2 ]; -int cpu_num; +int cpu_num =raw_smp_processor_id (); +struct cpuinfo_x86 *c = &cpu_data (cpu_num); - cpu_num =raw_smp_processor_id (); uci = ucode_cpu_info + cpu; mc_intel = uci->mc;@@ -317,7 +312,7 @@ static int apply_microcode(int cpu) (unsigned long) mc_intel->bits >> 16 >> 16);wrmsr (MSR_IA32_UCODE_REV ,0 ,0 ); -/* see notes above for revision 1.07. Apparent chip bug */ +/* As documented in the SDM: Do a CPUID 1 here */ sync_core ();/* get the current revision from MSR 0x8B */ @@ -335,6 +330,7 @@ static int apply_microcode(int cpu) (mc_intel->hdr.date >> 16) & 0xff); uci->cpu_sig.rev = val[1 ]; + c->cpu_update = val[1 ];return 0 ; }
Signature · 1 line
Jean Delvare