RE: [PATCH v3 1/2] apic: Fix error interrupt report at all APs

[Guo, Chaohong]

> -----Original Message-----
> From: Song, Youquan
> Sent: Saturday, January 08, 2011 10:20 AM
> To: linux-kernel@xxxxxxxxxxxxxxx; hpa@xxxxxxxxxxxxxxx; Siddha, Suresh B
> Cc: yong.y.wang@xxxxxxxxxxxxxxx; joe@xxxxxxxxxxx; jbaron@xxxxxxxxxx;
> arjan@xxxxxxxxxxxxxxx; trenn@xxxxxxx; Liu, Kent; Guo, Chaohong; Youquan
> Song; Song, Youquan
> Subject: [PATCH v3 1/2] apic: Fix error interrupt report at all APs
> 
> Recently, customer report that once machine boot, there are many error
> interrupt reported with exact number of all APs.
> 
> The root cause is Local APIC will generate error interrupt when it detect the
> illegal vector (one in 0 ~ 15) in an interrupt message received or interrupt
> generate from local vector table or self IPI. SDM3A.chapter 10.
> 
> AP LAPIC thermal sensor register will be reset to 0x10000, if thermal throttling
> interrupt take over by BIOS, it need restore AP with the thermal sensor register
> value of geting from BSP, otherwise cause system issue. If BIOS does not take
> over the thermal interrupt, The restore value will be CPU rest value of 0x10000,
> which means the interrupt vector is zero. After writing 0x10000 to thermal
> sensor LVT, the processor will recieve the error interrupt report if the APIC
> error interrupt is also set.
> 
> This patch add check the BIOS whether take over the thermal interrupt by look
> at interrupt delivery mode not fixed mode(BIOS handle will be SMI mode)
> before restore AP's thermal LVT. So the agony noise of error interrupt will
> dismiss when boot on machine that BIOS does not handle thermal interrupt..
> 
> 
> Signed-off-by: Youquan Song <youquan.song@xxxxxxxxx>
> Acked-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
> Acked-by: Yong Wang <yong.y.wang@xxxxxxxxx>
> ---
>  arch/x86/include/asm/apicdef.h           |    1 +
>  arch/x86/kernel/cpu/mcheck/therm_throt.c |   12 +++++++-----
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
> index a859ca4..1495098 100644
> --- a/arch/x86/include/asm/apicdef.h
> +++ b/arch/x86/include/asm/apicdef.h
> @@ -85,6 +85,7 @@
>  #define		APIC_DM_INIT		0x00500
>  #define		APIC_DM_STARTUP		0x00600
>  #define		APIC_DM_EXTINT		0x00700
> +#define		APIC_DM_MASK		0x00700
>  #define		APIC_VECTOR_MASK	0x000FF
>  #define	APIC_ICR2	0x310
>  #define		GET_APIC_DEST_FIELD(x)	(((x) >> 24) & 0xFF)
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index 4b68326..22a3b4f 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -405,18 +405,20 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
>  	 */
>  	rdmsr(MSR_IA32_MISC_ENABLE, l, h);
> 
> +	h = lvtthmr_init;
>  	/*
>  	 * The initial value of thermal LVT entries on all APs always reads
>  	 * 0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
>  	 * sequence to them and LVT registers are reset to 0s except for
>  	 * the mask bits which are set to 1s when APs receive INIT IPI.
> -	 * Always restore the value that BIOS has programmed on AP based on
> -	 * BSP's info we saved since BIOS is always setting the same value
> -	 * for all threads/cores
> +	 * If BIOS take over the thermal interrupt and set its interrupt
> +	 * delivery mode to SMI not fixed, it restore the value that BIOS has
> +	 * programmed on AP based on BSP's info we saved since BIOS is always
> +	 * setting the same value for all threads/cores.
>  	 */
> -	apic_write(APIC_LVTTHMR, lvtthmr_init);
> +	if (h & APIC_DM_MASK)

How about changing it to :

     If ( (h & APIC_DM_MASK) != APIC_DM_FIXED)

-minskey












> +		apic_write(APIC_LVTTHMR, lvtthmr_init);
> 
> -	h = lvtthmr_init;
> 
>  	if ((l & MSR_IA32_MISC_ENABLE_TM1) && (h & APIC_DM_SMI)) {
>  		printk(KERN_DEBUG
> --
> 1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/