On Mon, 31 Aug 2015 09:40:43 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Hi Marc,
On 08/31/2015 09:18 AM, Marc Zyngier wrote:
On Mon, 31 Aug 2015 08:47:07 -0700Looks like it.
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Hi Marc,
On 08/31/2015 08:31 AM, Marc Zyngier wrote:
On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Hi Guenter,
Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi
Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.
[...]
The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.
Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...
That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.
See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.
Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.
Please let me know if there is anything I can do to help tracking
this down.
I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:
- With -next as of today, qemu segfaults. Humpffff.
- If I use my branch that contains the EOImode==1 patch, the system
boots normally.
So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.
I did a couple of tests.
- Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
Same problem.
- Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
and 'irqchip/GIC: Convert to EOImode == 1'.
Problem is no longer seen.
This is getting even more weird. I've upgraded my qemu to 2.3 (the
latest Debian seems to be carrying). I'm booting a A15-TC1 model with
the following:
emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
-kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
-serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
none