From: Ingo Molnar <mingo@elte.hu>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Yong Wang <yong.y.wang@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86, therm: Only read the initial value of thermal LVT entry on BSP
Date: Sun, 8 Nov 2009 11:25:21 +0100 [thread overview]
Message-ID: <20091108102520.GC7233@elte.hu> (raw)
In-Reply-To: <1257562565.4083.485.camel@sbs-t61.sc.intel.com>
* Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> On Fri, 2009-11-06 at 16:17 -0800, Yong Wang wrote:
> > Only read the initial value of thermal LVT entry on BSP. 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 mask bits which are set to
> > 1s when APs receive INIT IPI.
> >
> > Also 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.
>
> Yong, I have appended a new patch with an enhanced change log and
> subject. In future, when you modify and post another version of the
> patch, can you please update the patch version and elaborate what has
> changed, why etc, so that it will be easier for the reviewers.
>
> Ingo/Peter, please review and queue this patch from Yong. Thanks.
> ---
>
> From: Yong Wang <yong.y.wang@intel.com>
> Subject: x86: under bios control, restore AP's APIC_LVTTHMR to the BSP value
>
> On platforms where bios handles the thermal monitor interrupt,
> APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS
> can't touch it.
>
> Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all
> the LVT entries except the mask bit. Essentially this results in
> all LVT entries including the thermal monitoring interrupt set to masked
> (clearing the bios programmed value for APIC_LVTTHMR).
>
> And this leads to kernel take over the thermal monitoring interrupt
> on AP's but not on BSP (leaving the bios programmed value only on BSP).
>
> As a result of this, we have seen system hangs when the thermal
> monitoring interrupt is generated.
>
> Fix this by reading the initial value of thermal LVT entry on BSP
> and if bios has taken over the control, then program the same value
> on all AP's and leave the thermal monitoring interrupt control
> on all the logical cpu's to the bios.
>
> Signed-off-by: Yong Wang <yong.y.wang@intel.com>
> Reviewed-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Cc: stable@kernel.org
> ---
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index b3a1dba..1fd42db 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -259,6 +259,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
> unsigned int cpu = smp_processor_id();
> int tm2 = 0;
> u32 l, h;
> + static u32 lvtthmr;
>
> /* Thermal monitoring depends on ACPI and clock modulation*/
> if (!cpu_has(c, X86_FEATURE_ACPI) || !cpu_has(c, X86_FEATURE_ACC))
> @@ -270,7 +271,24 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
> * since it might be delivered via SMI already:
> */
> rdmsr(MSR_IA32_MISC_ENABLE, l, h);
> - h = apic_read(APIC_LVTTHMR);
> +
> + /*
> + * Only read the initial value of thermal LVT entry on BSP. 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.
> + * Also 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 (cpu == 0)
> + lvtthmr = apic_read(APIC_LVTTHMR);
> + else
> + apic_write(APIC_LVTTHMR, lvtthmr);
> +
> + h = lvtthmr;
> +
i dont disagree with the fix, but could we please do it a bit cleaner,
and initialize a proper file-scope lvtthrm_init value from a different
boot-CPU-only function? (not intel_init_thermal)
that makes it cleaner, and also it will work if we dont boot on cpu==0.
(should that ever occur)
Thanks,
Ingo
next prev parent reply other threads:[~2009-11-08 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-07 0:17 [PATCH] x86, therm: Only read the initial value of thermal LVT entry on BSP Yong Wang
2009-11-07 2:56 ` Suresh Siddha
2009-11-07 9:52 ` Yong Wang
2009-11-08 10:25 ` Ingo Molnar [this message]
2009-11-08 12:38 ` Yong Wang
2009-11-08 13:16 ` Ingo Molnar
2009-11-08 13:19 ` Yong Wang
2009-11-08 15:59 ` Ingo Molnar
2009-11-08 13:42 ` Cyrill Gorcunov
-- strict thread matches above, loose matches on Subject: below --
2009-11-06 5:46 Yong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091108102520.GC7233@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=yong.y.wang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.