Re: KVM oops: killing interrupt handler

[Jiri Slaby]

On 2/11/07, Avi Kivity <avi@xxxxxxxxxxxx> wrote:
> Jiri Slaby wrote:
> > Hi!
> >
> > My schoolmate got this while using kvm-12 on 2.6.20-rc6:
> > http://www.fi.muni.cz/~xslaby/sklad/kvm-intel-panic/a/
> >
> > Unfortunately it's only shots taken by camera. If we are able to
> > reproduce it in 2.6.20, we'll grab netconsole output.
> >
>
> What guest? what host?  How to reproduce?

It's intel core 2 duo emulating 32-bit wxp. It happened after
suspend/resume (he doesn't know if qemu was actually running) of the
machine.

Dmesg (not with the oops):
http://www.fi.muni.cz/~xpapiez/kvm-intel-panic/dmesg.txt
.config:
http://www.fi.muni.cz/~xpapiez/kvm-intel-panic/config-2.6.20-rc6.txt

I don't know if this is related, but qemu-system-x86 ends up in D state:
root     28740  0.0  0.0      0     0 ?        D    14:31   0:00
[qemu-system-x86]
root     28858  0.0  0.0      0     0 ?        D    14:33   0:00
[qemu-system-x86]

qemu-system-x D 0000000000000002     0 28740  28738                     (L-TLB)
ffff810037455918 0000000000000046 0000000000000000 ffffffff8022d12c
0000000000000001 0000000080620536 0000000000000001 0000000000000001
0000000100000001 ffff81001133f8a0 ffff81003ff8e080 0000039ff2320d9f
Call Trace:
[<ffffffff8022d12c>] try_to_wake_up+0x44c/0x470
[<ffffffff802486a9>] autoremove_wake_function+0x9/0x30
[<ffffffff80475ab9>] __mutex_lock_slowpath+0x69/0xb0
[<ffffffff80475926>] mutex_lock+0x16/0x20
[<ffffffff886d1c8c>] :kvm:vcpu_load+0x2c/0x70
[<ffffffff886d1ce3>] :kvm:kvm_free_vcpu+0x13/0x40
[<ffffffff886d1dd8>] :kvm:kvm_dev_release+0x18/0x60
[<ffffffff80280785>] __fput+0xc5/0x1c0
[<ffffffff8027d811>] filp_close+0x71/0x90
[<ffffffff80234f57>] put_files_struct+0x87/0x110
[<ffffffff802362d3>] do_exit+0x263/0x850
[<ffffffff8036845c>] do_unblank_screen+0x7c/0x130
[<ffffffff8020b720>] kernel_math_error+0x0/0xb0
[<ffffffff8020c11d>] do_invalid_op+0xad/0xc0
[<ffffffff886e2418>] :kvm_intel:vmcs_clear+0x38/0x60
[<ffffffff80474bbb>] thread_return+0x0/0xf5
[<ffffffff80476dbd>] error_exit+0x0/0x84
[<ffffffff886e2418>] :kvm_intel:vmcs_clear+0x38/0x60
[<ffffffff886e3a21>] :kvm_intel:alloc_vmcs_cpu+0x61/0x80
[<ffffffff886e4b85>] :kvm_intel:vmx_create_vcpu+0x65/0xb0
[<ffffffff886d271a>] :kvm:kvm_dev_ioctl+0x1aa/0x1250
[<ffffffff8026252c>] get_page_from_freelist+0x2cc/0x370
[<ffffffff80262633>] __alloc_pages+0x63/0x2f0
[<ffffffff8025fff8>] filemap_nopage+0x198/0x350
[<ffffffff8026b21d>] __handle_mm_fault+0x5ed/0xad0
[<ffffffff8031ce81>] __up_read+0x21/0xb0
[<ffffffff80220b8f>] do_page_fault+0x49f/0x870
[<ffffffff802700e1>] do_mmap_pgoff+0x671/0x800
[<ffffffff8028be9f>] do_ioctl+0x2f/0xa0
[<ffffffff8028c1b2>] vfs_ioctl+0x2a2/0x2e0
[<ffffffff8028c239>] sys_ioctl+0x49/0x80
[<ffffffff80476dbd>] error_exit+0x0/0x84
[<ffffffff80209cfe>] system_call+0x7e/0x83

qemu-system-x D 0000000000000001     0 28858  28856                     (L-TLB)
ffff810017eb5918 0000000000000046 0000000000000000 ffffffff8022d12c
0000000000000001 0000000080620536 0000000000000001 0000000000000001
0000000100000001 ffff81003fb50e80 ffff81003ff8e080 000003b72f95dec6
Call Trace:
[<ffffffff8022d12c>] try_to_wake_up+0x44c/0x470
[<ffffffff802486a9>] autoremove_wake_function+0x9/0x30
[<ffffffff80475ab9>] __mutex_lock_slowpath+0x69/0xb0
[<ffffffff80475926>] mutex_lock+0x16/0x20
[<ffffffff886d1c8c>] :kvm:vcpu_load+0x2c/0x70
[<ffffffff886d1ce3>] :kvm:kvm_free_vcpu+0x13/0x40
[<ffffffff886d1dd8>] :kvm:kvm_dev_release+0x18/0x60
[<ffffffff80280785>] __fput+0xc5/0x1c0
[<ffffffff8027d811>] filp_close+0x71/0x90
[<ffffffff80234f57>] put_files_struct+0x87/0x110
[<ffffffff802362d3>] do_exit+0x263/0x850
[<ffffffff8036845c>] do_unblank_screen+0x7c/0x130
[<ffffffff8020b720>] kernel_math_error+0x0/0xb0
[<ffffffff8020c11d>] do_invalid_op+0xad/0xc0
[<ffffffff886e2418>] :kvm_intel:vmcs_clear+0x38/0x60
[<ffffffff80474bbb>] thread_return+0x0/0xf5
[<ffffffff80476dbd>] error_exit+0x0/0x84
[<ffffffff886e2418>] :kvm_intel:vmcs_clear+0x38/0x60
[<ffffffff886e3a21>] :kvm_intel:alloc_vmcs_cpu+0x61/0x80
[<ffffffff886e4b85>] :kvm_intel:vmx_create_vcpu+0x65/0xb0
[<ffffffff886d271a>] :kvm:kvm_dev_ioctl+0x1aa/0x1250
[<ffffffff8026252c>] get_page_from_freelist+0x2cc/0x370
[<ffffffff80262633>] __alloc_pages+0x63/0x2f0
[<ffffffff8025fff8>] filemap_nopage+0x198/0x350
[<ffffffff8026b21d>] __handle_mm_fault+0x5ed/0xad0
[<ffffffff8031ce81>] __up_read+0x21/0xb0
[<ffffffff80220b8f>] do_page_fault+0x49f/0x870
[<ffffffff802700e1>] do_mmap_pgoff+0x671/0x800
[<ffffffff8028be9f>] do_ioctl+0x2f/0xa0
[<ffffffff8028c1b2>] vfs_ioctl+0x2a2/0x2e0
[<ffffffff8028c239>] sys_ioctl+0x49/0x80
[<ffffffff80476dbd>] error_exit+0x0/0x84
[<ffffffff80209cfe>] system_call+0x7e/0x83

After killing X and trying reboot, oops is here again:
http://www.fi.muni.cz/~xslaby/sklad/kvm-intel-panic/a/kernel-panic-11.2.2007.jpg.png

Now I'm going to compile 2.6.20 and try to reproduce there.

thanks,
--
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/