On Fri, Apr 20, 2018 at 12:01:31PM +0200, Vitezslav Samel wrote:
> > Ok, cleaned up patches with commit messages coming up.
>
> Good.
Ok, here they are as a reply to this message. I'm running them here, you
could run them one last time to make sure all is good.
@Ashok: please run them too, bef
On Fri, Apr 20, 2018 at 11:52:20AM +0200, Borislav Petkov wrote:
> On Fri, Apr 20, 2018 at 08:20:21AM +0200, Vitezslav Samel wrote:
> > ;-) This time it works.
>
> Good. :-)
>
> > microcode: __reload_late: CPU1 waiting to exit
> > x86/CPU: CPU features have changed after loading microcode, but
On Fri, Apr 20, 2018 at 08:20:21AM +0200, Vitezslav Samel wrote:
> ;-) This time it works.
Good. :-)
> microcode: __reload_late: CPU1 waiting to exit
> x86/CPU: CPU features have changed after loading microcode, but might not
> take effect.
> x86/CPU: Please consider either early loading thro
On Thu, Apr 19, 2018 at 06:37:34PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 03:46:27PM +0200, Vitezslav Samel wrote:
> >
> > microcode: __reload_late: CPU0
> > microcode: __reload_late: CPU3
> > microcode: __reload_late: CP
On Thu, Apr 19, 2018 at 03:46:27PM +0200, Vitezslav Samel wrote:
>
> microcode: __reload_late: CPU0
> microcode: __reload_late: CPU3
> microcode: __reload_late: CPU2
> microcode: __reload_late: CPU1
> microcode: __reload_late: CPU0 reload
On Thu, Apr 19, 2018 at 05:32:18AM -0700, Raj, Ashok wrote:
> Thanks.. also can you remove the ret below, and send the output
> of /proc/cpuinfo before and after?
>
> On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> > } else {
> > + pr_info("%s: CPU%d returning 0x%x
On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 02:02:39PM +0200, Vitezslav Samel wrote:
> > Here it is:
>
> Thanks!
>
> > -
> > microcode: __reload_late: CPU1
> > microcode: __reload_late: CP
Thanks.. also can you remove the ret below, and send the output
of /proc/cpuinfo before and after?
On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> } else {
> + pr_info("%s: CPU%d returning 0x%x\n", __func__, cpu, err);
> return ret;
^^
On Thu, Apr 19, 2018 at 02:02:39PM +0200, Vitezslav Samel wrote:
> Here it is:
Thanks!
> -
> microcode: __reload_late: CPU1
> microcode: __reload_late: CPU3
> microcode: __reload_late: CPU2
> microcode: __reload_late: CPU0
> microcode:
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 bo
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.
> > - w
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.
> > - w
On Wed, Apr 18, 2018 at 06:53:30AM -0700, Raj, Ashok wrote:
> On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> > > I switched to firmware-in-kernel early loading and that works OK.
>
> firmware-in-kernel means y
On Wed, Apr 18, 2018 at 06:53:30AM -0700, Raj, Ashok wrote:
> nothing about the microcode itself comes to mind. I'm wondering if
> this similar to the Arch linux that used late-load during booting
> might be an issue.
How so?
They'd echo 1 > /sys/... very early during boot?
Got an example dmesg
On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> > I switched to firmware-in-kernel early loading and that works OK.
firmware-in-kernel means you compile your microcode image in linux?
Can you tell me which distr
On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> I switched to firmware-in-kernel early loading and that works OK.
Ok, and keep using that from now on.
People should all move away from that late loading dance. I'm saying
that in case someone else reads this on lkml.
> But still
On Wed, Apr 18, 2018 at 12:07:21PM +0200, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 10:11:40AM +0200, Vitezslav Samel wrote:
> > Could be done anything to prevent this panic?
>
> Yes, for starters, is there anything preventing you from using an initrd
> and doing early microcode loading?
On Wed, Apr 18, 2018 at 10:11:40AM +0200, Vitezslav Samel wrote:
> Could be done anything to prevent this panic?
Yes, for starters, is there anything preventing you from using an initrd
and doing early microcode loading?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Do
Hi!
Starting with 4.15.17 I got panic "timeout during microcode update"
which I bisected down to commit 8e1161f94614 ("x86/microcode: Synchronize
late microcode loading") - upstream commit
a5321aec6412b20b5ad15db2d6b916c05349dbff.
The panic happens during CPU microcode update.
The
19 matches
Mail list logo
