Re: [PULL v2 00/11] Misc patches for 2023-02-08

[Thomas Huth]

On 09/02/2023 16.17, Peter Maydell wrote:
> On Thu, 9 Feb 2023 at 09:36, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > The following changes since commit ae2b5d8381a73b27f35f19c988d45c78bb4d5768:
> >
> >    Merge tag 'pull-include-2023-02-06-v2' of https://repo.or.cz/qemu/armbru 
> > into staging (2023-02-08 10:40:06 +0000)
> >
> > are available in the Git repository at:
> >
> >    https://gitlab.com/bonzini/qemu.git tags/for-upstream
> >
> > for you to fetch changes up to 92f5d4606bedf0e2af0169a32aff9443084c5d0a:
> >
> >    target/i386: fix ADOX followed by ADCX (2023-02-09 10:17:34 +0100)
> >
> > ----------------------------------------------------------------
> > * block/iscsi: fix double-free on BUSY or similar statuses
> > * catch [accel] entry without accelerator
> > * target/i386: various fixes for BMI and ADX instructions
> > * make the contents of meson-buildoptions.sh stable
> >
> > ----------------------------------------------------------------
>
> This seems to consistently fail on the BSD jobs:
> https://gitlab.com/qemu-project/qemu/-/jobs/3742560167
> https://gitlab.com/qemu-project/qemu/-/jobs/3742560168
> https://gitlab.com/qemu-project/qemu/-/jobs/3743330014
> https://gitlab.com/qemu-project/qemu/-/jobs/3743330018
> https://gitlab.com/qemu-project/qemu/-/jobs/3743909430
>
> Unfortunately the logs don't seem very informative :-(

Out of curiosity, I added some debug printfs and ran the test a couple of 
more times in the CI. It's pretty weird... There are two problems in 
qtest_wait_qemu() :

1) In these FreeBSD runners, that "do { waitpid(..., WNOHANG) } while" loop 
does not finish in time, so the code sends a SIGKILL signal to the QEMU 
process. This then causes qtest_check_status() to abort() later since QEMU 
finished with a bad status. Should we handle this more gracefully so that 
the code does not abort() after the SIGKILL?

2) By increasing WAITPID_TIMEOUT to more than 75 seconds, I can make the 
test succeed. It's really weird, but it seems like the do-while loop always 
takes 75 seconds to succeed in case of the "invalid-accel" test - but I've 
got no clue where that delay could come from... Any ideas?

 Thomas