All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel C <nix.or.die@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kevin.b.stanton@intel.com, Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
Subject: Re: commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425
Date: Mon, 14 May 2018 16:16:23 +0200	[thread overview]
Message-ID: <CAEJqkggEAj+DfsYDKiKJFqn9gfsbZcZ52D1TY13RVh-ZomngWw@mail.gmail.com> (raw)
In-Reply-To: <20180514125856.GR12217@hirez.programming.kicks-ass.net>

2018-05-14 14:58 GMT+02:00 Peter Zijlstra <peterz@infradead.org>:
> On Mon, May 14, 2018 at 02:15:44PM +0200, Gabriel C wrote:
>> http://ftp.frugalware.org/pub/other/people/crazy/ucode/cpuinfo-ucode-20180312
>> http://ftp.frugalware.org/pub/other/people/crazy/ucode/cpuinfo-ucode-20180425
>
> That's 0xc2 and 0x9e respectively, for the microcode revision.
>
> For model 78 (INTEL_FAM6_SKYLAKE_MOBILE) we need at least 0xb2.
>
> Now, obviously 0xc2 is in fact larger than 0xb2, however 0x9e is
> smaller and it is rightfully complaining.
>
> Now, I have (debian testing):
>
> $ apt-cache show intel-microcode
> Package: intel-microcode
> Version: 3.20180425.1
>
> $ hexdump /lib/firmware/intel-ucode/06-4e-03 | head
> 0000000 0001 0000 00c2 0000 2017 1116 06e3 0004
> 0000010 f699 c6c6 0001 0000 00c0 0000 83d0 0001
> 0000020 8400 0001 0000 0000 0000 0000 0000 0000
>
> Which gives 0xc2 as version for your CPU.
>
> If I download microcode-20180425.tgz from:
>
>   https://downloadcenter.intel.com/download/27776/Linux-Processor-Microcode-Data-File
>
> I again get 0xc2 for 06-4e-03.
>
> So please double check your package...

Yes hexdump matches here too.

I've build a initramfs with the files from microcode-20180425.tgz (
with distro packages removed ) with the same result.

Maybe dracut is doing something stupid .. but  I'm not sure what since
the setup does not change just the ucode files.

I'll try to find out.

>
>> Loading microcode manually is working
>
> IIRC late loading doesn't re-evaluate any of this. If you down-grade you
> can 'wreck' your system.
>
>> Also initramfs is made with dracut and his early microcode option.
>
> Yes, early microcode should be the right thing.

I try to build an kernel with  built-in ucode file without a initrd
and figure whatever that works.

      reply	other threads:[~2018-05-14 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12 10:55 commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425 Gabriel C
2018-05-14  7:23 ` Peter Zijlstra
2018-05-14 12:15   ` Gabriel C
2018-05-14 12:58     ` Peter Zijlstra
2018-05-14 14:16       ` Gabriel C [this message]

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=CAEJqkggEAj+DfsYDKiKJFqn9gfsbZcZ52D1TY13RVh-ZomngWw@mail.gmail.com \
    --to=nix.or.die@gmail.com \
    --cc=kevin.b.stanton@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 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.