On 03/13/2018 09:02 AM, Peter Maydell wrote:
> On 12 March 2018 at 18:35, Eric Blake <eblake@redhat.com> wrote:
>> The following changes since commit 6ceb1b51f05f9e1892d082960ed602dca7b6696e:
>>
>> Merge remote-tracking branch 'remotes/kraxel/tags/audio-20180312-pull-request' into staging (2018-03-12 16:14:37 +0000)
>>
>> are available in the Git repository at:
>>
>> git://repo.or.cz/qemu/ericb.git tags/pull-qapi-2018-03-12
>>
>> for you to fetch changes up to a083c533b5a17c77ef164acdbf30eedfa9681fc6:
>>
>> qapi: add block latency histogram interface (2018-03-12 13:22:11 -0500)
>>
>> This builds and passes 'make check', so even though the OOB portion
>> depends on chardev fixes that are still pending a pull request from
>> Paolo, that dependence can only be observed at runtime by clients
>> that use the new oob feature. Given the timing of soft freeze, and
>> the fact that the chardev fixes do not form a build dependency, I
>> think it's okay if this pull request gets processed before Paolo's
>> (but it's also okay if Paolo's goes in first).
Based on the testsuite failures, it looks like Paolo's pull request with
chardev fixes DOES have to go in first. More at [1] below.
> x86/Linux and x86 OpenBSD, compile failure (probably gcc-version-dependent):
>
> /home/petmay01/linaro/qemu-for-merges/hw/i386/acpi-build.c: In
> function ‘build_append_pci_bus_devices’:
> /home/petmay01/linaro/qemu-for-merges/hw/i386/acpi-build.c:617:9:
> error: ‘notify_method’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> aml_append(parent_scope, notify_method);
> ^
> /home/petmay01/linaro/qemu-for-merges/hw/i386/acpi-build.c:510:16:
> note: ‘notify_method’ was declared here
> Aml *dev, *notify_method, *method;
> ^
> cc1: all warnings being treated as errors
Odd - The only mention of notify_method in that file in my series is in
the context:
$ git diff 6ceb1b51f..pull-qapi-2018-03-12 hw/i386/acpi-build.c \
|grep notify_method
notify_method = aml_method("DVNT", 2, AML_NOTSERIALIZED);
and where all the hunks look like:
@@ -154,21 +154,21 @@ static void acpi_get_pm_info(AcpiPmInfo *pm)
/* Fill in optional s3/s4 related properties */
o = object_property_get_qobject(obj, ACPI_PM_PROP_S3_DISABLED, NULL);
if (o) {
- pm->s3_disabled = qnum_get_uint(qobject_to_qnum(o));
+ pm->s3_disabled = qnum_get_uint(qobject_to(QNum, o));
which doesn't change control flow logic. So all I can guess is that
this has been a latent pre-existing problem, but the compiler is now
flagging it. At any rate, I can try and shut it up, and will spin a v2
once the other issue is solved.
>
> on PPC64 Linux, FreeBSD x86, OpenBSD x86, aarch64 Linux hosts, test fails;
> looks like the same assert but in different tests:
>
> ppc64:
> TEST: tests/qmp-test... (pid=48041)
> /alpha/qmp/protocol: OK
> /alpha/qmp/oob: OK
> /alpha/qmp/query-status: OK
> /alpha/qmp/query-block:
> qemu-system-alpha: /home/pm215/qemu/
> chardev/char-io.c:91: io_watch_poll_finalize: Assertion `iwp->src ==
> ((void *)0)' failed.
> Broken pipe
> FAIL
> GTester: last random seed: R02S3e793887202ca8b099adb20531a072e6
> (pid=48057)
>
[1] this is probably the chardev fixes being tickled by oob. (Weird
that the change is not failing the oob test, though - or is the failure
happening during cleanup of the oob test, AFTER it reported OK?) Here's
where I'm hoping Paolo's pull request with chardev fixes is the
solution, otherwise, I may have to disable Peter's OOB patches.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org