On Tue, Aug 26, 2025 at 09:45:48PM +0200, Anders Roxell wrote: > On 2025-08-14 07:28, Inochi Amaoto wrote: > > As the RISC-V PLIC can not apply affinity setting without calling > > irq_enable(), it will make the interrupt unavailble when using as > > an underlying IRQ chip for MSI controller. > > > > Implement .irq_startup() and .irq_shutdown() for the PCI MSI and > > MSI-X templates. For chips that specify MSI_FLAG_PCI_MSI_STARTUP_PARENT, > > these startup and shutdown the parent as well, which allows the > > irq on the parent chip to be enabled if the irq is not enabled > > when allocating. This is necessary for the MSI controllers which > > use PLIC as underlying IRQ chip. > > > > Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Signed-off-by: Inochi Amaoto <inochiama@xxxxxxxxx> > > Regressions found while booting the Linux next-20250826 on the > qemu-arm64, qemu-armv7 due to following kernel log. > > Bisection identified this commit as the cause of the regression. > > Regression Analysis: > - New regression? Yes > - Reproducible? Yes > > First seen on the next-20250826 > Good: next-20250825 > Bad: next-20250826 > > Test regression: next-20250826 gcc-13 boot failed on qemu-arm64 and > qemu-armv7. > > Expected behavior: System should boot normally and virtio block devices > should be detected and initialized immediately. > > Actual behavior: System hangs for ~30 seconds during virtio block device > initialization before showing scheduler deadline replenish errors and > failing to complete boot. > > Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx> > > [...] > <6>[ 1.369038] virtio-pci 0000:00:01.0: enabling device (0000 -> > 0003) > <6>[ 1.420097] Serial: 8250/16550 driver, 4 ports, IRQ sharing > enabled > <6>[ 1.450858] msm_serial: driver initialized > <6>[ 1.454489] SuperH (H)SCI(F) driver initialized > <6>[ 1.456056] STM32 USART driver initialized > <6>[ 1.513325] loop: module loaded > <6>[ 1.515744] virtio_blk virtio0: 2/0/0 default/read/poll queues > <5>[ 1.527859] virtio_blk virtio0: [vda] 5397504 512-byte logical > blocks (2.76 GB/2.57 GiB) > <4>[ 29.761219] sched: DL replenish lagged too much > [here it hangs] > > > Reverting this commit restores normal boot behavior. > > > qemu-arm64 > - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250826/testrun/29663822/suite/boot/test/gcc-13-lkftconfig/log > > qemu-armv7 > - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250826/testrun/29663615/suite/boot/test/gcc-13-lkftconfig/log > > ## Source > * Git tree: > * https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git > * Git sha: d0630b758e593506126e8eda6c3d56097d1847c5 > * Git describe: next-20250826 > * Project details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250826 > * Architectures: arm64 > * Toolchains: gcc-13 > * Kconfigs: gcc-13-lkftconfig > > > ## Build > * Test history: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250826/testrun/29663822/suite/boot/test/gcc-13-lkftconfig/history/ > * Test link: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/31oo1cMOi0uSNKYApi80iQahbLi > * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/31onzS5UmJVvvZucEhtB1veoJA1/ > * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/31onzS5UmJVvvZucEhtB1veoJA1/config > Is there a link for me to get the command line args for qemu? So I can reproduce it locally. Regards, Inochi
