From: Vitezslav Samel <vitezslav@samel.cz>
To: Borislav Petkov <bp@suse.de>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: 4.15.17 regression: bisected: timeout during microcode update
Date: Thu, 19 Apr 2018 14:02:39 +0200 [thread overview]
Message-ID: <20180419120239.GA2377@pc11.op.pod.cz> (raw)
In-Reply-To: <20180419104829.GE3896@pd.tnic>
On Thu, Apr 19, 2018 at 12:48:29PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 07:35:31AM +0200, Vitezslav Samel wrote:
> > > - Can you remove your builtin microcode,
> > > - rename the /lib/firmware/intel-ucode so we don't find it during late loading.
> > > - let the system boot completely
> > > - then rename the intel-ucode back for this test.
> > > - write 1 to reload and see if that update succeeds or fails?
> >
> > Just tested, it fails.
>
> Can you apply the below patch, do the exact same exercise and catch the
> output? Over serial console or netconsole or if nothing else, do a video
> of the screen with a phone and upload it somewhere?
Here it is:
-------------------------------------------------------------
microcode: __reload_late: CPU1
microcode: __reload_late: CPU3
microcode: __reload_late: CPU2
microcode: __reload_late: CPU0
microcode: __reload_late: CPU1 reloading
microcode: __reload_late: CPU3 reloading
microcode: __reload_late: CPU2 reloading
microcode: __reload_late: CPU0 reloading
microcode: __reload_late: CPU3 returning 0x0
microcode: __reload_late: CPU2 returning 0x0
microcode: updated to revision 0x24, date = 2018-01-21
microcode: __reload_late: CPU0 waiting to exit
microcode: __reload_late: CPU1 returning 0x0
microcode: Timeout while waiting for CPUs rendezvous, remaining: 3
Kernel panic - not syncing: Timeout during microcode update!
CPU: 0 PID: 11 Comm: migration/0 Not tainted 4.16.3+ #1
Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 2.2 02/05/2015
Call Trace:
dump_stack+0x46/0x65
panic+0xca/0x208
__reload_late+0x11e/0x120
multi_cpu_stop+0x55/0xa0
? cpu_stop_queue_work+0x80/0x80
cpu_stopper_thread+0x7d/0x100
? sort_range+0x20/0x20
smpboot_thread_fn+0x11f/0x1e0
kthread+0x101/0x120
? __kthread_create_on_node+0x150/0x150
? __kthread_create_on_node+0xf0/0x150
ret_from_fork+0x35/0x40
Shutting down cpus with NMI
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Timeout during microcode update!
-------------------------------------------------------------
Vita
>
> Thx.
>
> ---
> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> index 10c4fc2c91f8..374ec1d75d89 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -553,6 +553,8 @@ static int __reload_late(void *info)
> enum ucode_state err;
> int ret = 0;
>
> + pr_info("%s: CPU%d\n", __func__, cpu);
> +
> /*
> * Wait for all CPUs to arrive. A load will not be attempted unless all
> * CPUs show up.
> @@ -560,6 +562,8 @@ static int __reload_late(void *info)
> if (__wait_for_cpus(&late_cpus_in, NSEC_PER_SEC))
> return -1;
>
> + pr_info("%s: CPU%d reloading\n", __func__, cpu);
> +
> spin_lock(&update_lock);
> apply_microcode_local(&err);
> spin_unlock(&update_lock);
> @@ -571,9 +575,12 @@ static int __reload_late(void *info)
> } else if (err == UCODE_UPDATED || err == UCODE_OK) {
> ret = 1;
> } else {
> + pr_info("%s: CPU%d returning 0x%x\n", __func__, cpu, ret);
> return ret;
> }
>
> + pr_info("%s: CPU%d waiting to exit\n", __func__, cpu);
> +
> /*
> * Increase the wait timeout to a safe value here since we're
> * serializing the microcode update and that could take a while on a
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
> --
next prev parent reply other threads:[~2018-04-19 12:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 8:11 4.15.17 regression: bisected: timeout during microcode update Vitezslav Samel
2018-04-18 10:07 ` Borislav Petkov
2018-04-18 12:08 ` Vitezslav Samel
2018-04-18 12:22 ` Borislav Petkov
2018-04-18 13:53 ` Raj, Ashok
2018-04-18 16:14 ` Borislav Petkov
2018-04-19 5:35 ` Vitezslav Samel
2018-04-19 7:22 ` Raj, Ashok
2018-04-19 10:48 ` Borislav Petkov
2018-04-19 12:02 ` Vitezslav Samel [this message]
2018-04-19 12:18 ` Borislav Petkov
2018-04-19 12:32 ` Raj, Ashok
2018-04-19 13:48 ` Vitezslav Samel
2018-04-19 13:46 ` Vitezslav Samel
2018-04-19 16:37 ` Borislav Petkov
2018-04-20 6:20 ` Vitezslav Samel
2018-04-20 9:52 ` Borislav Petkov
2018-04-20 10:01 ` Vitezslav Samel
2018-04-20 10:32 ` Borislav Petkov
2018-04-20 10:34 ` [PATCH 1/2] x86/microcode/intel: Save microcode patch unconditionally Borislav Petkov
2018-04-20 10:54 ` Vitezslav Samel
2018-04-20 15:59 ` Raj, Ashok
2018-04-20 10:37 ` [PATCH 2/2] x86/microcode: Do not exit early from __reload_late() Borislav Petkov
2018-04-20 10:54 ` Vitezslav Samel
2018-04-20 16:00 ` Raj, Ashok
2018-04-21 8:19 ` [PATCH 1/2] x86/microcode/intel: Save microcode patch unconditionally Borislav Petkov
2018-04-21 8:19 ` [PATCH 2/2] x86/microcode: Do not exit early from __reload_late() Borislav Petkov
2018-04-24 7:52 ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2018-04-24 7:51 ` [tip:x86/urgent] x86/microcode/intel: Save microcode patch unconditionally tip-bot 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=20180419120239.GA2377@pc11.op.pod.cz \
--to=vitezslav@samel.cz \
--cc=ashok.raj@intel.com \
--cc=bp@suse.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.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 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.