Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Mar 12, 2014 at 04:09:20PM +0100, Atom2 wrote:
> 
> 
> 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 ... (:-)

Hehe.
> 
> 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).

Right. And Xen 4.4 is the one that got the ucode=scan code support :-)

> >
> >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