On 2022-12-03 11:14, Christian Kastner wrote:
> I'm also leaning towards a race, but the question is whether this is
> really a potential bug, or whether determinism is assumed where none is
> guaranteed (similar to the issue of storage devices like sda and sdb
> being non-deterministic).
I may have stumbled over a trivial solution.
Looking at Maximilian's test cases, I noticed that -device virtio-serial
was being specified multiple times. From other docs, I gather it's only
needed once, even with multiple devices.
The attached patch reduces this to one instance, and this fixes the
issue for me.
I ran a series of tests with armhf/arm64, various CPU counts, and all
went well. armhf with 4 CPUs initially failed but from using the
--show-boot option, it was evident that the boot process was just slower
(long time spent in GRUB), and with increasing --timeout=120, that
worked, too.
With Maximilian's experiments showing that the console count was
shifted, I guess that multiple -device virtio-serial somehow confuses
internal QEMU ordering, although I don't know why this would be an issue
only with kernels > 5.10.
Can anyone else give this patch a try before I submit an MR?
Best,
Christian
Index: autopkgtest-5.27/lib/autopkgtest_qemu.py
===================================================================
--- autopkgtest-5.27.orig/lib/autopkgtest_qemu.py
+++ autopkgtest-5.27/lib/autopkgtest_qemu.py
@@ -368,12 +368,15 @@ class Qemu:
'unix:%s,server=on,wait=off' % self.get_socket_path('hvc0'),
])
else:
+ if hvc == 'hvc0' or self.qemu_architecture == 'ppc64le':
+ argv.extend([
+ '-device', 'virtio-serial',
+ ])
argv.extend([
'-chardev',
'socket,path=%s,server=on,wait=off,id=%s' % (
self.get_socket_path(hvc), hvc,
),
- '-device', 'virtio-serial',
'-device', 'virtconsole,chardev=%s' % hvc,
])
