| Message ID | 20170809070357.28723-1-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: > The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74: > > Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100) > > are available in the git repository at: > > git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170809 > > for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87: > > spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000) > > ---------------------------------------------------------------- > ppc patch queue 2017-08-09 > > This series contains a number of bugfixes for ppc and related > machines, for the qemu-2.10.release. Some are true regressions, > others are serious enough and non-invasive enough to fix that it's > worth putting in 2.10 this late. > > ---------------------------------------------------------------- Applied, thanks. > I haven't completed a Travis build for this, which is part of my usual > test regime, since the first dozen or so Travis builds are failing > more often than not on master as well. I don't know why this is - > seems to be failing some of the x86 tests. Doesn't look much worse than usual to me -- of the last 24 travis builds for master 4 failed and 20 passed. thanks -- PMM
On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: > On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: > > The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74: > > > > Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100) > > > > are available in the git repository at: > > > > git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170809 > > > > for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87: > > > > spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000) > > > > ---------------------------------------------------------------- > > ppc patch queue 2017-08-09 > > > > This series contains a number of bugfixes for ppc and related > > machines, for the qemu-2.10.release. Some are true regressions, > > others are serious enough and non-invasive enough to fix that it's > > worth putting in 2.10 this late. > > > > ---------------------------------------------------------------- > > Applied, thanks. > > > I haven't completed a Travis build for this, which is part of my usual > > test regime, since the first dozen or so Travis builds are failing > > more often than not on master as well. I don't know why this is - > > seems to be failing some of the x86 tests. > > Doesn't look much worse than usual to me -- of the last 24 travis > builds for master 4 failed and 20 passed. Uh.. that's not been my experience. I was a bit unclear in my description, though. Until maybe a week and a half ago I found the Travis build was fairly reliable, though there were occasional transien failures. Now, essentially every Travis build is failing for me. Specifically most of the first dozen or so of the batch of build configurations on Travis fail (that's "X" not "!"). These seem to be transient failures in the sense that if I rebuild enough times they'll eventually pass, but unlike earlier when the builds would suceed most of the time, they now seem to succeed at best around 1/3 of the time (that's ~1/3 of the time for each configuration sub-build, so with a dozen or so apparently affected that means a complete passing build essentially never). See for example https://travis-ci.org/dgibson/qemu/builds/263312174 where 5 subbuilds have failed (which is relatively few). In each case the failing error seems to be something like: ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly Seems to be i386 in some cases and x86_64 in others.
On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote: > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: >> > I haven't completed a Travis build for this, which is part of my usual >> > test regime, since the first dozen or so Travis builds are failing >> > more often than not on master as well. I don't know why this is - >> > seems to be failing some of the x86 tests. >> >> Doesn't look much worse than usual to me -- of the last 24 travis >> builds for master 4 failed and 20 passed. > > Uh.. that's not been my experience. I was a bit unclear in my > description, though. Until maybe a week and a half ago I found the > Travis build was fairly reliable, though there were occasional > transien failures. Now, essentially every Travis build is failing for > me. Specifically most of the first dozen or so of the batch of build > configurations on Travis fail (that's "X" not "!"). These seem to be > transient failures in the sense that if I rebuild enough times they'll > eventually pass, but unlike earlier when the builds would suceed most > of the time, they now seem to succeed at best around 1/3 of the time > (that's ~1/3 of the time for each configuration sub-build, so with a > dozen or so apparently affected that means a complete passing build > essentially never). > > See for example https://travis-ci.org/dgibson/qemu/builds/263312174 > where 5 subbuilds have failed (which is relatively few). In each case > the failing error seems to be something like: > > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly > > Seems to be i386 in some cases and x86_64 in others. Weird. https://travis-ci.org/qemu/qemu/builds is the master build history and as you can see it's mostly greens. Not sure why your setup would be significantly worse: maybe one of the travis submaintainers has an idea. It could just be our vhost-user-test is flaky but I don't know why that should hit you much more than master... thanks -- PMM
Hi David, Peter, On 08/11/2017 05:59 AM, Peter Maydell wrote: > On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote: >> On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: >>> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: >>>> I haven't completed a Travis build for this, which is part of my usual >>>> test regime, since the first dozen or so Travis builds are failing >>>> more often than not on master as well. I don't know why this is - >>>> seems to be failing some of the x86 tests. >>> >>> Doesn't look much worse than usual to me -- of the last 24 travis >>> builds for master 4 failed and 20 passed. >> >> Uh.. that's not been my experience. I was a bit unclear in my >> description, though. Until maybe a week and a half ago I found the >> Travis build was fairly reliable, though there were occasional >> transien failures. Now, essentially every Travis build is failing for >> me. Specifically most of the first dozen or so of the batch of build >> configurations on Travis fail (that's "X" not "!"). These seem to be >> transient failures in the sense that if I rebuild enough times they'll >> eventually pass, but unlike earlier when the builds would suceed most >> of the time, they now seem to succeed at best around 1/3 of the time >> (that's ~1/3 of the time for each configuration sub-build, so with a >> dozen or so apparently affected that means a complete passing build >> essentially never). >> >> See for example https://travis-ci.org/dgibson/qemu/builds/263312174 >> where 5 subbuilds have failed (which is relatively few). In each case >> the failing error seems to be something like: >> >> ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly >> >> Seems to be i386 in some cases and x86_64 in others. Yes, I'm experiencing the same (but a bit more frequent with i386 than x86_64). > Weird. https://travis-ci.org/qemu/qemu/builds is the master > build history and as you can see it's mostly greens. > Not sure why your setup would be significantly worse: > maybe one of the travis submaintainers has an idea. > It could just be our vhost-user-test is flaky but I don't > know why that should hit you much more than master... No clue, I started to think repositories with less frequent builds are deployed on faster hardware. Will keep the list informed if there are some improvements. Regards, Phil.
On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote: > On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote: > > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: > >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: > >> > I haven't completed a Travis build for this, which is part of my usual > >> > test regime, since the first dozen or so Travis builds are failing > >> > more often than not on master as well. I don't know why this is - > >> > seems to be failing some of the x86 tests. > >> > >> Doesn't look much worse than usual to me -- of the last 24 travis > >> builds for master 4 failed and 20 passed. > > > > Uh.. that's not been my experience. I was a bit unclear in my > > description, though. Until maybe a week and a half ago I found the > > Travis build was fairly reliable, though there were occasional > > transien failures. Now, essentially every Travis build is failing for > > me. Specifically most of the first dozen or so of the batch of build > > configurations on Travis fail (that's "X" not "!"). These seem to be > > transient failures in the sense that if I rebuild enough times they'll > > eventually pass, but unlike earlier when the builds would suceed most > > of the time, they now seem to succeed at best around 1/3 of the time > > (that's ~1/3 of the time for each configuration sub-build, so with a > > dozen or so apparently affected that means a complete passing build > > essentially never). > > > > See for example https://travis-ci.org/dgibson/qemu/builds/263312174 > > where 5 subbuilds have failed (which is relatively few). In each case > > the failing error seems to be something like: > > > > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly > > > > Seems to be i386 in some cases and x86_64 in others. > > Weird. https://travis-ci.org/qemu/qemu/builds is the master > build history and as you can see it's mostly greens. > Not sure why your setup would be significantly worse: > maybe one of the travis submaintainers has an idea. > It could just be our vhost-user-test is flaky but I don't > know why that should hit you much more than master... So, Travis is telling me my builds are being done on a trusty environment (even the sub-builds which don't specify a distro explicitly). That doesn't seem to be the case for the master tree builds. Then again, the sub-builds which do specifically ask for trusty seem to be working, so I'm not sure why implicity choosing trusty would break things.
On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote: > On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote: > > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: > >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: > >> > I haven't completed a Travis build for this, which is part of my usual > >> > test regime, since the first dozen or so Travis builds are failing > >> > more often than not on master as well. I don't know why this is - > >> > seems to be failing some of the x86 tests. > >> > >> Doesn't look much worse than usual to me -- of the last 24 travis > >> builds for master 4 failed and 20 passed. > > > > Uh.. that's not been my experience. I was a bit unclear in my > > description, though. Until maybe a week and a half ago I found the > > Travis build was fairly reliable, though there were occasional > > transien failures. Now, essentially every Travis build is failing for > > me. Specifically most of the first dozen or so of the batch of build > > configurations on Travis fail (that's "X" not "!"). These seem to be > > transient failures in the sense that if I rebuild enough times they'll > > eventually pass, but unlike earlier when the builds would suceed most > > of the time, they now seem to succeed at best around 1/3 of the time > > (that's ~1/3 of the time for each configuration sub-build, so with a > > dozen or so apparently affected that means a complete passing build > > essentially never). > > > > See for example https://travis-ci.org/dgibson/qemu/builds/263312174 > > where 5 subbuilds have failed (which is relatively few). In each case > > the failing error seems to be something like: > > > > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly > > > > Seems to be i386 in some cases and x86_64 in others. And is it always the connect-fail test? > Weird. https://travis-ci.org/qemu/qemu/builds is the master > build history and as you can see it's mostly greens. > Not sure why your setup would be significantly worse: > maybe one of the travis submaintainers has an idea. > It could just be our vhost-user-test is flaky but I don't > know why that should hit you much more than master... > > > thanks > -- PMM
On Mon, Aug 14, 2017 at 05:20:21PM +0300, Michael S. Tsirkin wrote: > On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote: > > On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote: > > > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote: > > >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote: > > >> > I haven't completed a Travis build for this, which is part of my usual > > >> > test regime, since the first dozen or so Travis builds are failing > > >> > more often than not on master as well. I don't know why this is - > > >> > seems to be failing some of the x86 tests. > > >> > > >> Doesn't look much worse than usual to me -- of the last 24 travis > > >> builds for master 4 failed and 20 passed. > > > > > > Uh.. that's not been my experience. I was a bit unclear in my > > > description, though. Until maybe a week and a half ago I found the > > > Travis build was fairly reliable, though there were occasional > > > transien failures. Now, essentially every Travis build is failing for > > > me. Specifically most of the first dozen or so of the batch of build > > > configurations on Travis fail (that's "X" not "!"). These seem to be > > > transient failures in the sense that if I rebuild enough times they'll > > > eventually pass, but unlike earlier when the builds would suceed most > > > of the time, they now seem to succeed at best around 1/3 of the time > > > (that's ~1/3 of the time for each configuration sub-build, so with a > > > dozen or so apparently affected that means a complete passing build > > > essentially never). > > > > > > See for example https://travis-ci.org/dgibson/qemu/builds/263312174 > > > where 5 subbuilds have failed (which is relatively few). In each case > > > the failing error seems to be something like: > > > > > > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly > > > > > > Seems to be i386 in some cases and x86_64 in others. > > And is it always the connect-fail test? I think so, though I haven't checked every single failing output to make sure. > > > Weird. https://travis-ci.org/qemu/qemu/builds is the master > > build history and as you can see it's mostly greens. > > Not sure why your setup would be significantly worse: > > maybe one of the travis submaintainers has an idea. > > It could just be our vhost-user-test is flaky but I don't > > know why that should hit you much more than master... > > > > > > thanks > > -- PMM >
The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74: Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100) are available in the git repository at: git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170809 for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87: spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000) ---------------------------------------------------------------- ppc patch queue 2017-08-09 This series contains a number of bugfixes for ppc and related machines, for the qemu-2.10.release. Some are true regressions, others are serious enough and non-invasive enough to fix that it's worth putting in 2.10 this late. ---------------------------------------------------------------- I haven't completed a Travis build for this, which is part of my usual test regime, since the first dozen or so Travis builds are failing more often than not on master as well. I don't know why this is - seems to be failing some of the x86 tests. David Gibson (2): target/ppc: Implement TIDR target/ppc: Add stub implementation of the PSSCR Greg Kurz (2): ppc: fix double-free in cpu_post_load() spapr_drc: abort if object_property_add_child() fails KONRAD Frederic (1): booke206: fix MAS update on tlb miss Sam Bobroff (1): spapr: Fix bug in h_signal_sys_reset() hw/ppc/spapr_drc.c | 2 +- hw/ppc/spapr_hcall.c | 9 ++++----- target/ppc/cpu.h | 2 ++ target/ppc/machine.c | 1 - target/ppc/mmu_helper.c | 2 +- target/ppc/translate_init.c | 10 ++++++++++ 6 files changed, 18 insertions(+), 8 deletions(-)