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