qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v3 0/8] Block layer patches


From: Peter Maydell
Subject: Re: [PULL v3 0/8] Block layer patches
Date: Wed, 20 Nov 2024 13:19:39 +0000

On Wed, 20 Nov 2024 at 10:52, Kevin Wolf <kwolf@redhat.com> wrote:
>
> The following changes since commit e6459afb1ff4d86b361b14f4a2fc43f0d2b4d679:
>
>   Merge tag 'pull-target-arm-20241119' of 
> https://git.linaro.org/people/pmaydell/qemu-arm into staging (2024-11-19 
> 14:23:34 +0000)
>
> are available in the Git repository at:
>
>   https://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to 83987bf722b6b692bc745b47901be76a1c97140b:
>
>   vl: use qmp_device_add() in qemu_create_cli_devices() (2024-11-20 11:47:49 
> +0100)
>
> ----------------------------------------------------------------
> Block layer patches
>
> - Fix qmp_device_add() to not throw non-scalar options away (fixes
>   iothread-vq-mapping being silently ignored in device_add)
> - Fix qdev property crash with integer PCI addresses and JSON -device
> - iotests: Fix mypy failure
> - parallels: Avoid potential integer overflow
> - Fix crash in migration_is_running()

Hi; the hotplug_blk.py:HotPlug.test avocado seems to be failing:

https://gitlab.com/qemu-project/qemu/-/jobs/8423313170
https://gitlab.com/qemu-project/qemu/-/jobs/8423313162

[stdlog] 2024-11-20 12:49:35,669 avocado.test test L0740 ERROR| FAIL
1-tests/avocado/hotplug_blk.py:HotPlug.test -> AssertionError: 1 != 0
: Guest command failed: test -e /sys/block/vda

https://qemu-project.gitlab.io/-/qemu/-/jobs/8423313162/artifacts/build/tests/results/latest/test-results/09-tests_avocado_hotplug_blk.py_HotPlug.test/debug.log

Looks like the test called device_add, it succeeded, but
it didn't see the /sys/block/vda node appear in the guest.

(The test logic of "try the command, if it fails sleep for 1
second then try a second time and if that fails call it a
test error" doesn't seem super robust in the face of slow
CI runners, but OTOH it failed the same way on both jobs,
so I don't think that is the culprit here.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]