Re: [Xen-devel] [xen-unstable test] 58821: tolerable FAIL

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-06-22 at 17:00 +0100, Andrew Cooper wrote:
> On 22/06/15 16:36, Jan Beulich wrote:
> >>>> On 22.06.15 at 17:17, <ian.campbell@xxxxxxxxxx> wrote:
> >> On Mon, 2015-06-22 at 14:09 +0000, osstest service user wrote:
> >>> flight 58821 xen-unstable real [real]
> >>> http://logs.test-lab.xenproject.org/osstest/logs/58821/ 
> >>>
> >> [...]
> >>>  test-amd64-amd64-libvirt     11 guest-start                  fail   like 
> >> 58789
> >>
> >> http://logs.test-lab.xenproject.org/osstest/logs/58821/test-amd64-amd64-libv
> >>  
> >> irt/info.html
> >>
> >> While investigating why libvirt hasn't been succeeding very well on
> >> merlot* I came across some things in the serial log which initially
> >> struck me as odd, but which I suspect are nothing (or at least not
> >> terribly relevant), if someone could confirm that would be great.
> >>
> >> Firstly is:
> >>
> >> Jun 22 12:41:09.633294 (XEN) microcode: CPU2 updated from revision 
> >> 0x6000822 to 0x6000832
> >> Jun 22 12:41:09.665099 (XEN) microcode: CPU4 updated from revision 
> >> 0x6000822 to 0x6000832
> >> Jun 22 12:41:09.729089 (XEN) microcode: CPU6 updated from revision 
> >> 0x6000822 to 0x6000832
> >> [...]
> >>
> >> i.e. only even numbered cpus are updated. (0 was done earlier in boot).
> >> I suspect that the answer here is "hyperthreading", and the cpuinfo
> >> shows all cpus have in fact been updated.
> > Yes (albeit hyperthreading is an Intel term, but iirc the same applies
> > to the two cores per compute unit).
> 
> Indeed.  The "microcode: patch is already at required level or
> greater.\n" message is helpfully unconditionally compiled out.
> 
> >
> >> The second thing is:
> >> Jun 22 12:41:10.601103 (XEN) Brought up 32 CPUs
> >> Jun 22 12:41:10.625270 (XEN) Testing NMI watchdog on all CPUs: 0 1 2 3 4 5 
> >> 6 
> >> 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 stuck
> >>
> >> i.e. at least one CPU has issues with NMI watchdog (looking at other
> >> runs it seems to vary between 29-31). Is this just that the NMI watchdog
> >> doesn't deal well with so many pCPUs? Or is it a real issue?
> > Very few CPUs properly responding is certainly quite odd; one
> > would expect all or none of them to work. Perhaps our AMD
> > maintainers (now Cc-ed) could take a look...
> 
> There are several things wrong with the NMI testing in Xen atm,
> following some recent investigation in XenServer.  Time isn't accounted
> properly for cores under bios/hardware power control, and Xen doesn't
> wait for the requisite time even if the core were running at its
> expected frequency.
> 
> I should see about making those patches appear, but for now, ignore this
> line.  It is more than likely wrong.

Thanks. I think that means all three issues are not something wrong with
the host, so I shall ignore them

(which leaves me none the wiser about the actual failure, oh well...)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel