Re: [Qemu-devel] [PULL v1 00/11] Merge qio 2016/10/27

[Peter Maydell]

On 27 October 2016 at 22:46, Peter Maydell <address@hidden> wrote:
> On 27 October 2016 at 22:40, Daniel P. Berrange <address@hidden> wrote:
>> On Thu, Oct 27, 2016 at 04:33:27PM +0100, Peter Maydell wrote:
>>> On 27 October 2016 at 16:10, Peter Maydell <address@hidden> wrote:
>>> > On 27 October 2016 at 13:57, Daniel P. Berrange <address@hidden> wrote:
>>> >> The following changes since commit 
>>> >> da158a86c407fa7b9da848b571356a26809d8df9:
>>> >>
>>> >>   Merge remote-tracking branch 
>>> >> 'remotes/berrange/tags/pull-qcrypto-2016-10-20-1' into staging 
>>> >> (2016-10-20 14:46:19 +0100)
>>> >>
>>> >> are available in the git repository at:
>>> >>
>>> >>   git://github.com/berrange/qemu tags/pull-qio-2016-10-27-1
>>> >>
>>> >> for you to fetch changes up to c3ff757d25115d6a530e8859d7287a862b1dc02d:
>>> >>
>>> >>   main: set names for main loop sources created (2016-10-27 09:13:11 
>>> >> +0200)
>>> >>
>>> >> ----------------------------------------------------------------
>>> >> Merge qio 2016/10/27 v1
>>> >>
>>> >> ----------------------------------------------------------------
>>> >
>>> > I see a test failure on AArch64 host:
>>> >
>>> > QTEST_QEMU_BINARY=s390x-softmmu/qemu-system-s390x
>>> > QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM %
>>> > 255 + 1))} gtester -k --verbose -m=quick tests/boot-serial-test
>>> > tests/device-introspect-test tests/qom-test
>>> > TEST: tests/boot-serial-test... (pid=4634)
>>> >   /s390x/boot-serial/s390-ccw-virtio:                                  **
>>> > ERROR:/home/petmay01/qemu/tests/boot-serial-test.c:67:check_guest_output:
>>> > assertion failed: (output_ok)
>>> > FAIL
>>> > GTester: last random seed: R02S101fdac2efbcab4bf5dcf8532b810b7a
>>> > (pid=7844)
>>> > FAIL: tests/boot-serial-test
>>>
>>> It didn't fail on a rerun, though...
>>
>> That's an odd looking fail. I've not tested on an aarch64 host myself,
>> but I did push this series through Travis CI twice, so its had ~40
>> build jobs which passed on x86_64 hosts at least.
>
> I suspect that machine of sometimes being very heavily
> loaded, so perhaps we just time out too quickly.
>
> I'll have another go at reprocessing this pull after
> I get through the backlog of other stuff.

It worked fine second time around, so I've pushed it to master.
I think the problem (if any) is not something in this patchset.

thanks
-- PMM