Message ID | 20180312183628.394722-1-eblake@redhat.com |
---|---|
State | New |
Headers | show |
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). > > ---------------------------------------------------------------- > qapi patches for 2018-03-12, 2.12 softfreeze > > - Marc-André Lureau: 0/4 qapi: generate a literal qobject for introspection > - Max Reitz: 0/7 block: Handle null backing link > - Peter Xu: 00/23 QMP: out-of-band (OOB) execution support > - Vladimir Sementsov-Ogievskiy: 0/2 block latency histogram > Hi; I'm afraid this failed some of my build tests: 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 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) aarch64: /aarch64/qmp/query-qmp-schema: OK /aarch64/qmp/query-version: OK /aarch64/qmp/query-commands: Assertion failed: (iwp->src == NULL) , function io_watch_poll_finalize, file /root/qemu/chardev/char-io.c, line 91. Broken pipe FAIL GTester: last random seed: R02Sbd982a1e1da0c16d183f7725739b58af (pid=58277) and the others are the same but in /mips64/device/introspect/abstract-interfaces /alpha/qmp/query-named-block-nodes thanks -- PMM
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.
On Tue, Mar 13, 2018 at 09:17:36AM -0500, Eric Blake wrote: > 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. [...] > > > > 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. Yes it is. The failure can possibly happen randomly on very random tests if without the whole bunch of chardev patches. I confirmed with Paolo offlist that all the chardev fixes will be in Paolo's next chardev pull request for the softfreeze. So with Paolo's next pull request, all the tests should pass, with 100%. If it still fails any, then please feel free to drop the whole OOB series so that I'll rework after 2.12. Sorry again for the troublesome.
On 03/13/2018 09:17 AM, Eric Blake wrote: >>> 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. Nearing the end of my workday; I'm not sure what the status is on Paolo's pull request with the chardev fixes, but hope that it doesn't invalidate this pull request from still being considered as soft freeze material.
On 13 March 2018 at 21:55, Eric Blake <eblake@redhat.com> wrote: > On 03/13/2018 09:17 AM, Eric Blake wrote: >>>> >>>> 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. > > > Nearing the end of my workday; I'm not sure what the status is on Paolo's > pull request with the chardev fixes, but hope that it doesn't invalidate > this pull request from still being considered as soft freeze material. The freeze approach is that if you get v1 of the pull on the list before the date, then the purpose of the following week before rc0 is to get the stragglers in and so that we can do re-spins if there were minor issues with anything. So it's ok. thanks -- PMM