On 06/29/2017 05:23 PM, Michael Holzheu wrote:
> Am Thu, 29 Jun 2017 12:48:28 +0300
> schrieb Pavel Emelyanov <xemul@xxxxxxxxxxxxx>:
>
>> On 06/28/2017 07:11 PM, Michael Holzheu wrote:
>>> Hello CRIU mailing list,
>>>
>>> This set of patches adds the s390x (64 bit mainframe) backend support to
>>> the CRIU checkpoint/restore tool.
>>
>> That's really cool :) thanks a lot!
>>
>> There's one, quite big, thing I'd like to discuss :) So far the most active community
>> members are x86 guys, but we already have 3 more arches (arm, aarch64 and ppc64le).
>> In order not to break non-x86 heavily we've set up travis-ci jobs to constantly check
>> that criu compiles on non-x64 [1]. Also we have arm box and access to ppc64 VM from
>> IBM and a set of jenkins jobs [2] that run tests on them.
>>
>> Would you also at least add the former piece, so that we don't break compilation of your
>> code. And ideally, we'd like to have the latter thing too.
>
> Yesterday we tried to setup the travis qemu stuff, but for some reason
> this failed. I attached our current patch to this E-mail.
OK. So we'll at least have the compilation checker :)
> Regarding [2] I will ask if we can provide something for s390.
That's awesome!
>>> The patches apply to the "criu-dev" branch on top of commit eee68d7a0
>>> ("aarch/vdso: include common/compiler.h before use __maybe_unused).
>>>
>>> On s390 all tests of the zdtm testsuite succeed on Ubuntu 16.04 with kernel
>>> 4.8.0-34-generic execpt for the following:
>>>
>>> - zdtm/static/del_standalone_un
>>> - zdtm/static/deleted_unix_sock
>>> - zdtm/static/mnt_ext_dev
>>> - zdtm/static/overmount_dev
>>> - zdtm/static/overmount_fifo
>>> - zdtm/static/overmount_file
>>> - zdtm/static/overmount_sock
>>> - zdtm/static/pthread02
>>> - zdtm/static/ptrace_sig
>>> - zdtm/static/scm00
>>
>> Erm ... this test is marked with crfail in its .desc file, which means, that
>> dump MUST fail :)
>
> Good to know, from the output below we just thought something is wrong :-)
>
> ~/criu/test (ibm_criu-dev)# ./zdtm.py run -t zdtm/static/scm00
> === Run 1/1 ================ zdtm/static/scm00
>
> ========================== Run zdtm/static/scm00 in h ==========================
> Start test
> ./scm00 --pidfile=scm00.pid --outfile=scm00.out
> Run criu dump
> =[log]=> dump/zdtm/static/scm00/26/1/dump.log
> ------------------------ grep Error ------------------------
> (00.002506) 26 fdinfo 5: pos: 0 flags: 2/0
> (00.002509) Searching for socket c786 (family 1.0)
> (00.002510) Searching for socket c785 (family 1.0)
> (00.002515) No filter for socket
> (00.002523) Error (criu/sk-queue.c:78): Control messages in queue, not supported
> (00.002531) ----------------------------------------
> (00.002539) Error (criu/cr-dump.c:1427): Dump files (pid: 26) failed with -1
> (00.002897) ptrace_set_regs: pid=26
> (00.002951) Unlock network
> (00.002955) Unfreezing tasks into 1
> (00.002957) Unseizing 26 into 1
> (00.002969) Error (criu/cr-dump.c:1797): Dumping FAILED.
> ------------------------ ERROR OVER ------------------------
> Send the 15 signal to 26
> Wait for zdtm/static/scm00(26) to die for 0.100000
> Removing dump/zdtm/static/scm00/26
> ========================= Test zdtm/static/scm00 PASS ==========================
This very line says that something indeed went wrong and that's what was expected :D
>>
>>> - zdtm/static/sock_peercred
>>> - zdtm/static/socket_snd_addr
>>
>> And this one is marked as 'noauto' which means, that the test is a placeholder
>> for the functionality we want to support, so it does fail now.
>
> Ok
>
>> How did you run the tests?
>
> We start the tests with "./zdtm.py run -a -x $exclude_list" because
> "make test" stops for the first failing test. Is there a better way to
> do it?
No, that's the correct command :) You should always look at the very last
line of each test, it says whether the test passed or not. Also, you may
want to use the --keep-going option, so that all tests are run and then
at the very end a summary is printed.
-- Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
