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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.06.15 at 17:17, <ian.campbell@citrix.com> 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).

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

> Lastly the eventual "'0' pressed -> dumping Dom0's registers" thing only
> seems to dump cpus 0..9 (inclusive). It seems to vary a bit. I suspect
> this is another "didn't wait long enough" thing, possibly on the osstest
> end.

This looks like an issue with the serial line not coping with the amount
of output (and hence dropping bits). Later on in the log there's also
quite large an unreadable part, which I would also attribute to such
a problem.

Jan