Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages

[Andreas Herrmann <herrmann.der.user@googlemail.com>]

On Thu, Nov 05, 2009 at 07:40:53PM +0100, Dmitry Adamushko wrote:
> 2009/11/5 Andreas Herrmann <herrmann.der.user@googlemail.com>:
> > The patches don't properly work here.
> >
> > (1) For instance I got following log entries when doing
> >    suspend/resume, doing CPU offline/online test and reloading the
> >    module:
> 
> To avoid possible misunderstandings, I'd like to clarify the output below.
> 
> >  microcode: original microcode versions...
> >  microcode: CPU0-3: patch_level=0x1000065
> 
> So this is the 1st time you have loaded a module.
> 
> >  platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
> >  ...
> >  microcode: CPU0-1,3: patch_level=0x1000083
> 
> before or after loading a module? CPU2 is down, isn't it?

No, no CPU was offline at this moment. They all were brought back
online after some CPU hotplug and/or suspend/resume tests.
 
> >  microcode: CPU2-3: patch_level=0x1000065

Both messages showed up after same ucode-update process.
 
> same question as above.

Same answer as above all CPUs are online.

> Here, either CPUs 0 and 1 are down or have a
> different version. Both above messages don't make sense taken together

See, and that's the problem.

> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly
> broken.

I didn't check that yet.

> >  Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> >
> > The patch levels are:
> >
> >  # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
> >  PATCH_LEVEL          = 0x0000000001000083
> >  PATCH_LEVEL          = 0x0000000001000083
> >  PATCH_LEVEL          = 0x0000000001000065
> >  PATCH_LEVEL          = 0x0000000001000065
> 
> this is after your test has been stopped and all the CPUs are up, right?

Yes.

> > (2) During suspend/resume the ucode is not updated:
> >
> >  hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
> >  PATCH_LEVEL          = 0x0000000001000083
> >  PATCH_LEVEL          = 0x0000000001000083
> >  PATCH_LEVEL          = 0x0000000001000083
> >  PATCH_LEVEL          = 0x0000000001000083
> >  hadburg linux # pm-suspend
> >  hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
> >  PATCH_LEVEL          = 0x0000000001000065
> >  PATCH_LEVEL          = 0x0000000001000065
> >  PATCH_LEVEL          = 0x0000000001000065
> >  PATCH_LEVEL          = 0x0000000001000065
> >
> >
> > That used to work w/o your patches. Didn't have time to look why this
> > is now failing. You've changed mc_cpu_callback() -- most likely that
> > is causing this regression.
> 
> Hmm, cpu-event-callbacks seem to be working on my (Intel) setup. I
> have enabled pr_debug messages and also did a little trick to allow
> ucode of the same version to be loaded (my cpu is of the recent ucode
> by itself) and I can see cpu-callback events for both resuming and
> cpu-up cases.
> 
> (firstly, upgraded with microcode_ctl as I only have a .dat file)
> 
> suspend-resume
> ...
> [  584.506371] microcode: CPU1 removed
> [  584.516018] microcode: CPU0 updated to revision 0x57, date = 2007-03-15
> [  584.597326] microcode: CPU1 updated upon resume
> [  584.597562] microcode: CPU1 updated to revision 0x57, date = 2007-03-15
> [  584.597565] microcode: CPU1 added
> ...
> 
> and now cpu1 : down -> up
> 
> [ 1616.932249] microcode: CPU1 removed
> [ 1633.942502] platform microcode: firmware: requesting intel-ucode/06-0f-02
> [ 1633.954638] microcode: data file intel-ucode/06-0f-02 load failed
> [ 1633.954642] microcode: CPU1 added
> 
> 
> as I understand, you don't see " platform microcode: firmware:
> requesting intel-ucode" messages upon 'upping' a cpu, do you?

Sure, no intel-ucode messages as I tested with AMD CPUs ;-)
But otherwise no, no messages.

> sure, my test is somewhat limited... anyway, first of all I'd like to
> get a clear understanding of your logs. Thanks for yout test btw. :-))

I'll send you full logs asap.


Regards,
Andreas