15342 2024-01-11 11:43:50 +0000 Serial issue with 6.6.9 linux-yocto 2024-11-14 15:58:47 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 0.0.0 x86 Multiple RESOLVED WORKSFORME https://bugzilla.yoctoproject.org/show_bug.cgi?id=15230 AB-INT Medium+ normal 5.2 M3 1 richard.purdie bruce.ashfield alexandre.belloni paulg randy.macleod richard.purdie tom.zanussi --- --- No (bug/feature does not impact docs) oldest_to_newest 97772 0 richard.purdie 2024-01-11 11:43:50 +0000 overlayfs.OverlayFSEtcRunTimeTests.test_sbin_init_preinit: FAILED (376.31s) https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/6291 AssertionError: False is not true : run_serial(): command timed out after 60 seconds without output >>> What is more interesting are the kernel logs from that failure: https://autobuilder.yocto.io/pub/failed-builds-data/linux-6.6/qemu_boot_log.20240110211938 which shows lots of: __common_interrupt: 3.37 No irq handler for vector For comparison there are some good boot logs from the same build here: https://autobuilder.yocto.io/pub/failed-builds-data/linux-6.6/success/ The other serial port logs are there too but don't show anything interesting. Looks like some new intermittent serial irq glitch in the 6.6 series. 98064 1 paulg 2024-01-30 19:39:10 +0000 So, I was tempted to assume that the reproducer for this would be the same as for case 15230 - since the error message was the same: pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n", __func__, smp_processor_id(), vector); But there are key differences. The 15230 was on x86-32, with kvm support disabled. This is on x86-64 with kvm support enabled. The 15230 would hard-hang right at the NOP rewrite at early boot. The logs in this case indicate the target/image did actually boot to a command prompt. The 15230 was always on CPU zero, with a range of different vectors reported. This is on CPU three, and we don't have enough data to if the vector remains the same, as AFAIK it has only been seen once. So it may be that the only thing the two cases share is the error message itself? Hard to say at this point. 100164 2 randy.macleod 2024-11-14 15:58:47 +0000 Not seen on the new infrastructure so it may have been load related. No fix was make as far as we know on the YP bug call.