qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [BUG] Possible ACPI regression in v2.1.0


From: Luiz Capitulino
Subject: [Qemu-devel] [BUG] Possible ACPI regression in v2.1.0
Date: Wed, 20 Aug 2014 16:41:25 -0400

Starting a QEMU instance manually configured to boot a Fedora installation
kernel with the -kernel/-initrd command-line options cause ACPI to brake
in the guest with the following messages:

[    0.000000] ACPI: uC\xffffffcdT 000000003ffe1854 2009587B (v49 
\xffffffb2?a\xffffffdf?? \xffffffca\xffffffe2???\xffffffa6K\xfffffffc 4CFA21C8 
\xffffffa1\xfffffff5\xffffffa5[ 2AA2CAF0)
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:536 
__early_ioremap+0x12b/0x1ce()
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.10-301.fc20.x86_64 
#1
[    0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[    0.000000]  0000000000000009 ffffffff81c01d58 ffffffff816441db 
0000000000000000
[    0.000000]  ffffffff81c01d90 ffffffff8106715d 0000000000000000 
000000003ffe1000
[    0.000000]  0000000000000000 0000000000000854 0000000000000000 
ffffffff81c01da0
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff816441db>] dump_stack+0x45/0x56
[    0.000000]  [<ffffffff8106715d>] warn_slowpath_common+0x7d/0xa0
[    0.000000]  [<ffffffff8106723a>] warn_slowpath_null+0x1a/0x20
[    0.000000]  [<ffffffff81d264a1>] __early_ioremap+0x12b/0x1ce
[    0.000000]  [<ffffffff81d26371>] ? __early_set_fixmap+0x97/0x9c
[    0.000000]  [<ffffffff81d2672a>] early_ioremap+0x13/0x15
[    0.000000]  [<ffffffff81d1e173>] __acpi_map_table+0x13/0x18
[    0.000000]  [<ffffffff8163dbaa>] acpi_os_map_memory+0x26/0x14e
[    0.000000]  [<ffffffff81d51037>] acpi_tb_parse_root_table+0x187/0x2c3
[    0.000000]  [<ffffffff813863c9>] ? acpi_find_root_pointer+0x11b/0x15e
[    0.000000]  [<ffffffff81d511ca>] acpi_initialize_tables+0x57/0x59
[    0.000000]  [<ffffffff81d4ef97>] acpi_table_init+0x1b/0x99
[    0.000000]  [<ffffffff81d1e523>] acpi_boot_table_init+0x1e/0x85
[    0.000000]  [<ffffffff81d1609f>] setup_arch+0xbc3/0xcec
[    0.000000]  [<ffffffff81d0ebbc>] start_kernel+0xcf/0x416
[    0.000000]  [<ffffffff81d0e120>] ? early_idt_handlers+0x120/0x120
[    0.000000]  [<ffffffff81d0e5de>] x86_64_start_reservations+0x2a/0x2c
[    0.000000]  [<ffffffff81d0e6e8>] x86_64_start_kernel+0x108/0x117
[    0.000000] ---[ end trace 0d4a133504d48174 ]---

...

[    0.148843] ACPI: Interpreter disabled

As the ACPI support in the guest kernel is not functional, QEMU won't be
notified when the guest is powered off by the user which in turn won't
cause QEMU to emit QMP events and change the RunState from "running" to
"paused". This in turn cause problems to libvirt too.

I bisected this and the culprit is:

commit 868270f23d8db2cce83e4f082fe75e8625a5fbf9
Author: Michael S. Tsirkin <address@hidden>
Date:   Mon Jul 28 23:07:11 2014 +0200

    acpi-build: tweak acpi migration limits

Indeed, if I revert that commit everything works as expected.

Here is my full reproducer. Please, note that I didn't cook that reproducer
myself. This problem was originally reported as a libvirt/QMP problem.

1. Download initrd.img and vmlinuz from  a fedora mirror (eg. 
http://fedora.mirror.lstn.net/releases/20/Fedora/x86_64/os/images/pxeboot/)

2. Run QEMU with:

# qemu -enable-kvm -m 1024 -no-shutdown \
    -boot strict=on -kernel /home/lcapitulino/files/vmlinuz \
    -initrd /home/lcapitulino/files/initrd.img \
    -append method=http://fedora.mirror.lstn.net/releases/20/Fedora/x86_64/os/  
\
    -drive file=/var/lib/libvirt/images/rhel7.img,if=virtio \
    -monitor stdio -vnc :0 -qmp tcp:0:4444,nowait,server

3. After the kernel boots, switch to to the installer shell:

(qemu) sendkey ctrl-alt-f2

4. Check if the kernel's ACPI interpreter has been enabled

# dmesg | grep -i interpreter
[    0.148843] ACPI: Interpreter disabled



reply via email to

[Prev in Thread] Current Thread [Next in Thread]