Re: Failed pipeline for migration.next | qemu | 9c21e614

[Dr. David Alan Gilbert]

* GitLab (gitlab@mg.gitlab.com) wrote:
> 
> 
> Pipeline #330351156 has failed!
> 
> Project: qemu ( https://gitlab.com/dagrh/qemu )
> Branch: migration.next ( 
> https://gitlab.com/dagrh/qemu/-/commits/migration.next )
> 
> Commit: 9c21e614 ( 
> https://gitlab.com/dagrh/qemu/-/commit/9c21e61435e09a7a67f951a096b93183a7a5ad89
>  )
> Commit Message: migration/rdma: Use error_report to suppress er...
> Commit Author: Li Zhijian
> Committed by: Dr_ David Alan Gilbert ( https://gitlab.com/dagrh )
> 
> Pipeline #330351156 ( https://gitlab.com/dagrh/qemu/-/pipelines/330351156 ) 
> triggered by Dr_ David Alan Gilbert ( https://gitlab.com/dagrh )
> had 2 failed jobs.
> 
> Job #1392645834 ( https://gitlab.com/dagrh/qemu/-/jobs/1392645834/raw )
> 
> Stage: build
> Name: build-disabled
> Job #1392645971 ( https://gitlab.com/dagrh/qemu/-/jobs/1392645971/raw )

Hmm,  that's:

Running test qtest-mips64/qom-test
Running test qtest-s390x/qom-test
Running test qtest-arm/npcm7xx_pwm-test
Running test qtest-i386/migration-test
../tests/qtest/libqtest.c:166: kill_qemu() detected QEMU death from signal 11 
(Segmentation fault) (core dumped)
ERROR qtest-i386/migration-test - too few tests run (expected 13, got 2)
make: *** [Makefile.mtest:72: run-test-7] Error 1

so perhaps that's a real migration-test failure running a 32bit qemu;
running the test on 32bit guest and making sure I had a /dev/kvm in my
32bit world (which I didn't in my pre-pull test), I see:

/i386/migration/fd_proto: [Detaching after fork from child process 201847]
[Detaching after fork from child process 201855]
qemu-system-i386: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=0, 
start=0x0, size=0xa0, errno=-14
qemu-system-i386: kvm_log_clear: kvm log clear failed: mr=pc.ram offset=0 
size=a0000
qemu-system-i386: check_section_footer: Read section footer failed: -5
Broken pipe
qemu-system-i386: load of migration failed: Invalid argument

Thread 1 "migration-test" received signal SIGABRT, Aborted.
0xf7fd2559 in __kernel_vsyscall ()
(gdb) where
#0  0xf7fd2559 in __kernel_vsyscall ()
#1  0xf7bb7382 in __libc_signal_restore_set (set=0xffffce9c) at 
../sysdeps/unix/sysv/linux/internal-signals.h:84
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf7ba12b6 in __GI_abort () at abort.c:79
#4  0x565603f5 in qmp_fd_receive (fd=4) at 
../home/source/tests/qtest/libqtest.c:618
#5  0x5656044b in qtest_qmp_receive_dict (s=0x565cebe0) at 
../home/source/tests/qtest/libqtest.c:646
#6  0x56560491 in qtest_qmp_receive (s=0x565cebe0) at 
../home/source/tests/qtest/libqtest.c:634
#7  0x56560d1a in qtest_vqmp (s=0x565cebe0, fmt=0x56594f90 "{ 'execute': 
'query-migrate' }", ap=0xffffd218 "") at 
../home/source/tests/qtest/libqtest.c:747
#8  0x5655ec77 in wait_command (who=0x565cebe0, command=0x56594f90 "{ 
'execute': 'query-migrate' }") at 
../home/source/tests/qtest/migration-helpers.c:63
#9  0x5655ef1d in migrate_query (who=0x565cebe0) at 
../home/source/tests/qtest/migration-helpers.c:107
#10 0x5655c79a in read_ram_property_int (who=<optimized out>, 
property=0x56594166 "dirty-sync-count") at 
../home/source/tests/qtest/migration-test.c:176
#11 0x5655c851 in get_migration_pass (who=0x565cebe0) at 
../home/source/tests/qtest/migration-test.c:215
#12 wait_for_migration_pass (who=0x565cebe0) at 
../home/source/tests/qtest/migration-test.c:215
#13 0x5655e773 in test_migrate_fd_proto () at 
../home/source/tests/qtest/migration-test.c:1038
#14 0xf7effbd7 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#15 0xf7effa77 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#16 0xf7effa77 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#17 0xf7effec9 in g_test_run_suite () from /lib/i386-linux-gnu/libglib-2.0.so.0
#18 0xf7effeed in g_test_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#19 0x5655b424 in main (argc=<optimized out>, argv=<optimized out>) at 
../home/source/tests/qtest/migration-test.c:1496

which hmm, doesn't look like a new test, I see kvm_log_clear has had a
fix to it's error handling in January from thuth, but perhaps that means
it's broken on 32bit on 64 for a while?


> Stage: test
> Name: check-python-tox

That one hmm I dunno, it's tox stuff.

Dave

> -- 
> You're receiving this email because of your account on gitlab.com.
> 
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK