From: Atom2 <ariel.atom2@web2web.at>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
daniel.kiper@oracle.com, david.vrabel@citrix.com,
Jan Beulich <JBeulich@suse.com>,
Yang Z Zhang <yang.z.zhang@intel.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
boris.ostrovsky@oracle.com
Subject: Re: How many patches are missing in upstream Linux?
Date: Wed, 12 Mar 2014 16:09:20 +0100 [thread overview]
Message-ID: <532078A0.1000702@web2web.at> (raw)
In-Reply-To: <20140312135022.GC3245@phenom.dumpdata.com>
Am 12.03.14 14:50, schrieb Konrad Rzeszutek Wilk:
> On Wed, Mar 12, 2014 at 12:58:13PM +0100, Atom2 wrote:
> I am still not sure why it does not work for you but it works for me so
> perhaps:
>
> a) the cpio archive is not being parsed by the 'ucode=scan' code.
> The patch attached can help in narrowing that possibility.
>
> b). The blobs are corrupted (also the patch below should help with that).
>
> c). Somethng else :-)
>
> Could you kindly try the attached patch? That should help in figuring out
> one of these options above.
I'd be very happy to be of help here - but, and that appears to be odd,
my version of xen does _NOT_ contain a function microcode_scan_module.
So your patch won't apply and fails for hunk #2 and #3:
# patch -p1 --dry-run < microcode-debug.patch
(Stripping trailing CRs from patch.)
patching file xen/arch/x86/microcode.c
Hunk #2 FAILED at 138.
Hunk #3 FAILED at 155.
2 out of 3 hunks FAILED -- saving rejects to file
xen/arch/x86/microcode.c.rej
(Stripping trailing CRs from patch.)
patching file xen/arch/x86/microcode_intel.c
On the other hand I guess that missing function certainly does explain
why the system can't scan and thus can't find the payload included in
the module. So in the end, I guess I nevertheless have been able to
somehow help ... (:-)
As the update with a separate module (multiboot) works, the rest of the
infrastructure for microcode updates seems to be there and working.
Is the function microcode_scan_module not part of the upstream xen that
is being used by distributions? Or did just gentoo miss something here -
although Jeremy also said that he was unable to get it to work unless
provided in a separate file? Though I have no clue what distribution he
is using ...
BTW the version of XEN I'm using is 4.3.1-r5 (the latest stable version
of gentoo).
>
> You should see something like this (this is on a SandyBridge) if it works:
>
> $xl dmesg | grep -i microcode
> (XEN) microcode payload @1 found (576512)
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
> (XEN) microcode: CPU0 found a matching microcode update with version 0x29 (current=0x28)
> (XEN) microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
> (XEN) microcode: CPU1 found a matching microcode update with version 0x29 (current=0x28)
> (XEN) microcode: CPU1 updated from revision 0x28 to 0x29, date = 2013-06-12
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
> (XEN) microcode: CPU3 found a matching microcode update with version 0x29 (current=0x28)
> (XEN) microcode: CPU3 updated from revision 0x28 to 0x29, date = 2013-06-12
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
> (XEN) microcode: CPU2 found a matching microcode update with version 0x29 (current=0x28)
> (XEN) microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
> (XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
next prev parent reply other threads:[~2014-03-12 15:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 5:21 How many patches are missing in upstream Linux? Zhang, Yang Z
2014-03-06 10:38 ` Jan Beulich
2014-03-06 13:47 ` Fabio Fantoni
2014-03-06 19:26 ` Konrad Rzeszutek Wilk
2014-03-06 19:36 ` David Vrabel
2014-03-06 19:39 ` Konrad Rzeszutek Wilk
2014-03-07 1:35 ` Zhang, Yang Z
2014-03-07 1:49 ` Zhang, Yang Z
2014-03-07 9:16 ` Jan Beulich
2014-03-10 20:55 ` Jeremy Fitzhardinge
2014-03-11 15:04 ` Konrad Rzeszutek Wilk
2014-03-11 16:15 ` Jan Beulich
2014-03-11 17:38 ` Konrad Rzeszutek Wilk
2014-03-11 17:38 ` Atom2
2014-03-11 17:53 ` Konrad Rzeszutek Wilk
2014-03-11 18:35 ` Atom2
2014-03-11 20:33 ` Konrad Rzeszutek Wilk
2014-03-12 1:00 ` Atom2
2014-03-12 8:20 ` Jan Beulich
2014-03-12 11:14 ` Atom2
2014-03-12 11:42 ` Jan Beulich
2014-03-12 11:58 ` Atom2
2014-03-12 13:50 ` Konrad Rzeszutek Wilk
2014-03-12 15:09 ` Atom2 [this message]
2014-03-12 16:30 ` Konrad Rzeszutek Wilk
2014-03-11 13:32 ` Ian Campbell
2014-03-11 15:09 ` Konrad Rzeszutek Wilk
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=532078A0.1000702@web2web.at \
--to=ariel.atom2@web2web.at \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=daniel.kiper@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xenproject.org \
--cc=yang.z.zhang@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 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).