Hi Jan,
On 28/04/2022 08:45, Jan Beulich wrote:
On 27.04.2022 19:10, Julien Grall wrote:
Hi,
On 27/04/2022 17:38, osstest service owner wrote:
flight 169781 xen-unstable-smoke real [real]
flight 169785 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169781/
http://logs.test-lab.xenproject.org/osstest/logs/169785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs.
169773
Well, I was overly optimistic :(. This now breaks in the ITS code:
Apr 27 13:23:14.324831 (XEN) Xen call trace:
Apr 27 13:23:14.324855 (XEN) [<000000000022a678>]
alloc_xenheap_pages+0x178/0x194 (PC)
Apr 27 13:23:14.336856 (XEN) [<000000000022a670>]
alloc_xenheap_pages+0x170/0x194 (LR)
Apr 27 13:23:14.336886 (XEN) [<0000000000237770>] _xmalloc+0x144/0x294
Apr 27 13:23:14.348773 (XEN) [<00000000002378d4>] _xzalloc+0x14/0x30
Apr 27 13:23:14.348808 (XEN) [<000000000027b4e4>]
gicv3_lpi_init_rdist+0x54/0x324
Apr 27 13:23:14.348835 (XEN) [<0000000000279898>]
arch/arm/gic-v3.c#gicv3_cpu_init+0x128/0x46c
Apr 27 13:23:14.360799 (XEN) [<0000000000279bfc>]
arch/arm/gic-v3.c#gicv3_secondary_cpu_init+0x20/0x50
Apr 27 13:23:14.372796 (XEN) [<0000000000277054>]
gic_init_secondary_cpu+0x18/0x30
Apr 27 13:23:14.372829 (XEN) [<0000000000284518>]
start_secondary+0x1a8/0x234
Apr 27 13:23:14.372856 (XEN) [<0000010722aa4200>] 0000010722aa4200
Apr 27 13:23:14.384793 (XEN)
Apr 27 13:23:14.384823 (XEN)
Apr 27 13:23:14.384845 (XEN) ****************************************
Apr 27 13:23:14.384869 (XEN) Panic on CPU 2:
Apr 27 13:23:14.384891 (XEN) Assertion '!in_irq() &&
(local_irq_is_enabled() || num_online_cpus() <= 1)' failed at
common/page_alloc.c:2212
Apr 27 13:23:14.396805 (XEN) ****************************************
The GICv3 LPI code contains a few calls to xmalloc() that will be done
while initializing the GIC CPU interface. I don't think we can delay the
initialization of the LPI part past local_irq_enable(). So I think we
will need to allocate the memory when preparing the CPU.
Do you have an explanation why the next flight (169800) passed?
The flight 169800 ran on laxtonX (Softiron) which doesn't have a GICv3 ITS.
I thought OSSTest would try to run the next flight on the same HW to
check heisenbug, but maybe this doesn't happen for the smoke test?
Cheers,
--
Julien Grall
