| Summary: | AB-INT: oe-selftest-armhost: Failed to start QEMU (hangs with drm) | ||
|---|---|---|---|
| Product: | [QA/Testing] Runtime Testing | Reporter: | Mathieu Dubois-Briand <mathieu.dubois-briand> |
| Component: | oeqa/runtime | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | kexin.hao, randy.macleod, richard.purdie, ross.burton, yoann.congal |
| Version: | unspecified | ||
| Target Milestone: | 6.1 | ||
| Hardware: | ARM | ||
| OS: | Multiple | ||
| Whiteboard: | AB-INT | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Mathieu Dubois-Briand
2026-01-26 15:10:15 UTC
oe-selftest-armhost ubuntu2504-vk-arm1 master completed at 2026-01-26 02:48:56+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3221/steps/15/logs/stdio Richard checked the logs after this occurred but didn't find anything useful. qemuarm64-ptest ubuntu2204-vk-arm2 master completed at 2026-02-27 10:42:08+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/61/builds/3131/steps/13/logs/stdio Logs from that build: https://valkyrie.yocto.io/pub/shared-failure-data/qemu_boot_log.20260227100156.2 https://valkyrie.yocto.io/pub/shared-failure-data/log.do_testimage.816104 Nothing 'interesting' I could find. One note is that there is no corresponding qemu_boot_log.20260227100156 That serial port seems to only have data after console init. https://valkyrie.yocto.io/pub/shared-failure-data/16150-success/ contains output from a successful ptest run from the same build for comparison Interestingly, one log has "printk: legacy console [hvc0] enabled", the other does not Since I was curious, I tried this:
Index: printk/printk.c
===================================================================
--- a/kernel/printk.orig/printk.c
+++ b/kernel/printk/printk.c
@@ -3979,6 +3979,9 @@ void register_console(struct console *ne
u64 init_seq;
int err;
+ if (strcmp(newcon->name, "hvc") == 0)
+ mdelay(500);
+
console_list_lock();
for_each_console(con) {
which did change the logs to look like:
[ 0.691950] virtio-pci 0000:00:05.0: enabling device (0000 -> 0003)
[ 0.693791] virtio-pci 0000:00:06.0: enabling device (0000 -> 0002)
[ 0.762657] [drm] pci: virtio-gpu-pci detected at 0000:00:06.0
[ 0.763553] [drm] features: -virgl +edid -resource_blob -host_visible
[ 0.763557] [drm] features: -context_init
[ 0.766006] [drm] number of scanouts: 1
[ 0.766028] [drm] number of cap sets: 0
[ 1.261454] printk: legacy console [hvc0] enabled
[ 1.261948] [drm] Initialized virtio_gpu 0.1.0 for 0000:00:06.0 on minor 0
[ 1.268542] Console: switching to colour frame buffer device 160x50
[ 1.273368] virtio-pci 0000:00:06.0: [drm] fb0: virtio_gpudrmfb frame buffer device
[ 1.278279] brd: module loaded
[ 1.278859] virtio_blk virtio2: 4/0/0 default/read/poll queues
so I was able to delay the console line to after most of the drm lines but now the virtio_gpu line and not the console switching
I was pointed at: https://www.kernel.org/doc/Documentation/admin-guide/serial-console.rst """ The behavior is more complicated when the same device type is defined more times. In this case, there are the following two rules: 1. The output will appear only on the first device of each defined type. 2. ``/dev/console`` will be associated with the first registered device. Where the registration order depends on how kernel initializes various subsystems. """ so is /dev/console sometimes going somewhere else? Would that explain the "hang"? To try and rule out ordering completely, I deferred the hvc console init by patching:
Index: drivers/tty/hvc/hvc_console.c
===================================================================
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -243,7 +243,7 @@ static int __init hvc_console_init(void)
register_console(&hvc_console);
return 0;
}
-console_initcall(hvc_console_init);
+late_initcall(hvc_console_init);
/* callback when the kboject ref count reaches zero. */
static void hvc_port_destruct(struct tty_port *po
This did move the printk line much later in the boot but didn't reproduce the "hang". It seems there is therefore something else going on here...
pkgman-non-rpm debian12-vk-7 master&master-next completed at 2026-03-19 16:10:23+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/67/builds/3445/steps/19/logs/stdio qemuarm-tc debian12-vk-9 master-next completed at 2026-03-26 19:24:51+00:00 https://valkyrie.yocto.io/pub/non-release/20260326-108/testresults/qemuarm-tc/ https://autobuilder.yoctoproject.org/valkyrie/#/builders/42/builds/3415/steps/13/logs/stdio qemuarm64-musl-ptest ubuntu2504-vk-arm1 master-next completed at 2026-04-02 11:01:54+00:00 https://valkyrie.yocto.io/pub/non-release/20260402-63/testresults/qemuarm64-musl-ptest/ https://autobuilder.yoctoproject.org/valkyrie/#/builders/109/builds/204/steps/13/logs/stdio qemuarm-alt ubuntu2510-vk-1 master-next completed at 2026-04-04 00:04:53+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/74/builds/3496/steps/15/logs/stdio oe-selftest-armhost ubuntu2404-vk-arm1 mathieu/master-next completed at 2026-04-14 19:33:19+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3762/steps/15/logs/stdio A BSP-ish issue, CCing Kexin from our BSP team who -may be able- to find time to work on this. qemuarm64-ptest ubuntu2404-vk-arm1 whinlatter completed at 2026-04-17 02:24:36+00:00 https://autobuilder.yoctoproject.org/valkyrie/?#/builders/61/builds/3503 qemuarm64-ptest ubuntu2404-vk-arm1 master completed at 2026-04-24 02:07:47+00:00 https://valkyrie.yocto.io/pub/non-release/20260424-8/testresults/qemuarm64-ptest/ https://autobuilder.yoctoproject.org/valkyrie/#/builders/61/builds/3554/steps/13/logs/stdio qemuarm-alt debian12-vk-9 mathieu/master-next completed at 2026-05-05 07:23:33+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/74/builds/3677/steps/14/logs/stdio oe-selftest-armhost ubuntu2404-vk-arm1 master&master-next completed at 2026-05-19 07:15:33+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3968/steps/15/logs/stdio Bulk move of 6.0 Medium bugs to 6.1. qemuarm64-musl-ptest ubuntu2404-vk-arm2 master&master-next completed at 2026-06-04 00:51:57+00:00 https://valkyrie.yocto.io/pub/non-release/20260603-116/testresults/qemuarm64-musl-ptest/ https://autobuilder.yoctoproject.org/valkyrie/#/builders/109/builds/494/steps/13/logs/stdio qemuarm debian12-vk-7 mathieu/master-next completed at 2026-06-24 08:54:32+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/16/builds/4026/steps/14/logs/stdio oe-selftest-armhost ubuntu2404-vk-arm1 master&mathieu/master-next completed at 2026-06-26 12:15:05+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/4208/steps/15/logs/stdio qemuarm-oecore debian11-vk-3 master completed at 2026-06-30 11:54:53+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/40/builds/4015/steps/13/logs/stdio oe-selftest-armhost ubuntu2404-vk-arm2 mathieu/master-next completed at 2026-07-08 19:41:22+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/4306/steps/15/logs/stdio qemuarm64-ptest ubuntu2404-vk-arm1 master-next completed at 2026-07-21 17:23:03+00:00 https://valkyrie.yocto.io/pub/non-release/20260721-84/testresults/qemuarm64-ptest/ https://autobuilder.yoctoproject.org/valkyrie/#/builders/61/builds/4066/steps/13/logs/stdio |