linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>, James Feeney <james@nurealm.net>,
	linux-smp@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	lkml <linux-kernel@vger.kernel.org>,
	Zhang Rui <rui.zhang@intel.com>, x86-ml <x86@kernel.org>
Subject: Re: [PATCH] x86/thermal: Fix LVT thermal setup for SMI delivery mode
Date: Thu, 27 May 2021 13:28:59 -0700	[thread overview]
Message-ID: <7e45be0d83c823fa48bac3494bed0eb9b71b8425.camel@linux.intel.com> (raw)
In-Reply-To: <YK/sjypdlYbk/NHC@zn.tnic>

On Thu, 2021-05-27 at 21:01 +0200, Borislav Petkov wrote:
> On Thu, May 27, 2021 at 11:09:59AM -0700, Srinivas Pandruvada wrote:
> > My guess is that system is booting hot sometimes. SMM started fan
> > or
> > some cooling and set a temperature threshold. It is waiting for
> > thermal
> > interrupt for temperature threshold, which it never got.
> 
> Are you saying that that replication of lvtthmr_init to the APs in
> intel_init_thermal() is absolutely needed on those SMI machines
> running
> hot?

We have seen some SMM uses thermal interrupts. We had one issue in one
Yoga systems several years back where SMM handling of thermal interrupt
related to HWP caused hard hang as it crashed there.
So yes, there may be special thing for cooling also.

> 
> That thing:
> 
>          * If BIOS takes over the thermal interrupt and sets its
> interrupt
>          * delivery mode to SMI (not fixed), it restores the value
> that the
>          * BIOS has programmed on AP based on BSP's info we saved
> since BIOS
>          * is always setting the same value for all threads/cores.
> 
> ?
> 
> Me moving that lvtthmr_init read later would replicate the wrong
> value
> because we'd soft-disable the APIC and thus the core would lockup
> waiting...
I think so.
I will try to force replicate wrong value in Yoga system which used to
crash in thermal interrupt handling of SMM code and check what happens.
 This shouldn't crash as it will not get thermal interrupt. Since the
system is not with me, I can try next week.

> 
> The other interesting thing is that the core would always lockup when
> trying to IPI another core to remote-flush the TLBs.
> 
Here I think the other core didn't exit SMM mode.

Thanks,
Srinivas



  reply	other threads:[~2021-05-27 20:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8a9599b2-f4fe-af9b-90f5-af39c315ec2f@nurealm.net>
2021-05-17  8:32 ` linux 5.12 - fails to boot - soft lockup - CPU#0 stuck for 23s! - RIP smp_call_function_single Borislav Petkov
2021-05-19  3:58   ` James Feeney
2021-05-19 11:12     ` Borislav Petkov
2021-05-19 20:03       ` James Feeney
2021-05-19 21:18         ` Borislav Petkov
2021-05-20  3:12           ` James Feeney
2021-05-20  9:21             ` Borislav Petkov
2021-05-21 22:11               ` James Feeney
2021-05-22  9:06                 ` Borislav Petkov
2021-05-22 23:28                   ` James Feeney
2021-05-23 17:05                     ` Borislav Petkov
2021-05-23 23:02                       ` James Feeney
2021-05-24  7:51                         ` Borislav Petkov
2021-05-25  4:02                           ` James Feeney
2021-05-27 10:31                             ` [PATCH] x86/thermal: Fix LVT thermal setup for SMI delivery mode Borislav Petkov
2021-05-27 11:49                               ` Thomas Gleixner
2021-05-27 11:56                                 ` Borislav Petkov
2021-05-27 18:54                                 ` Borislav Petkov
2021-05-28  8:23                                   ` Thomas Gleixner
2021-05-28 11:19                                     ` Borislav Petkov
2021-05-31 18:26                                       ` James Feeney
2021-05-27 18:09                               ` Srinivas Pandruvada
2021-05-27 19:01                                 ` Borislav Petkov
2021-05-27 20:28                                   ` Srinivas Pandruvada [this message]
2021-05-28  7:05                               ` James Feeney
2021-05-31 21:46   ` [tip: x86/urgent] " tip-bot2 for Borislav Petkov

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=7e45be0d83c823fa48bac3494bed0eb9b71b8425.camel@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=james@nurealm.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-smp@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).