Bug 15342

Summary: Serial issue with 6.6.9 linux-yocto
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Richard Purdie <richard.purdie>
Component: kernelAssignee: Bruce Ashfield <bruce.ashfield>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Medium+ CC: alexandre.belloni, paulg, randy.macleod, richard.purdie, tom.zanussi
Version: 0.0.0   
Target Milestone: 5.2 M3   
Hardware: x86   
OS: Multiple   
See Also: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15230
Whiteboard: AB-INT
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Richard Purdie 2024-01-11 11:43:50 UTC 
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.
Comment 1 Paul Gortmaker 2024-01-30 19:39:10 UTC 
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.
Comment 2 Randy MacLeod 2024-11-14 15:58:47 UTC 
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.