[Xen-devel] [xen-unstable-smoke test] 122468: regressions - FAIL

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

flight 122468 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. 
vs. 122457

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  2f64a251fa10dd4d62f84967e3dafa709f5e96ab
baseline version:
 xen                  7c894b8bac8eb62deb543291cb9fe7b813dd4fc8

Last test of basis   122457  2018-04-26 22:01:03 Z    0 days
Testing same since   122468  2018-04-27 13:00:36 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     fail    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 2f64a251fa10dd4d62f84967e3dafa709f5e96ab
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 27 14:35:35 2018 +0200

    x86/cpuidle: don't init stats lock more than once
    
    Osstest flight 122363, having hit an NMI watchdog timeout, shows CPU1 at
    
    Xen call trace:
       [<ffff82d08023d3f4>] _spin_lock+0x30/0x57
       [<ffff82d0802d9346>] update_last_cx_stat+0x29/0x42
       [<ffff82d0802d96f3>] cpu_idle.c#acpi_processor_idle+0x2ff/0x596
       [<ffff82d080276713>] domain.c#idle_loop+0xa8/0xc3
    
    and CPU0 at
    
    Xen call trace:
       [<ffff82d08023d173>] on_selected_cpus+0xb7/0xde
       [<ffff82d0802dbe22>] powernow.c#powernow_cpufreq_target+0x110/0x1cb
       [<ffff82d080257973>] __cpufreq_driver_target+0x43/0xa6
       [<ffff82d080256b0d>] cpufreq_governor_dbs+0x324/0x37a
       [<ffff82d080257bf2>] __cpufreq_set_policy+0xfa/0x19d
       [<ffff82d080256044>] cpufreq_add_cpu+0x3a1/0x5df
       [<ffff82d0802dbab4>] cpufreq_cpu_init+0x17/0x1a
       [<ffff82d0802567a8>] set_px_pminfo+0x2b6/0x2f7
       [<ffff82d08029f1bf>] do_platform_op+0xe75/0x1977
       [<ffff82d0803712c5>] pv_hypercall+0x1f4/0x440
       [<ffff82d0803784a5>] lstar_enter+0x115/0x120
    
    That is, Dom0's ACPI processor driver is in the process of uploading Px
    and Cx data. Looking at the ticket lock state in CPU1's registers, it is
    waiting for ticket 0x0000 to have its turn, while the supposed current
    owner's ticket is 0x0001, which is an invalid state (and neither of the
    other two CPUs holds the lock anyway). Hence I can only conclude that
    cpuidle_init_cpu(1) ran on CPU 0 while some other CPU held the lock (the
    unlock then put the lock in the state that CPU1 is observing).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel