crash with Ubuntu12.04 64bit guest on Ubuntu12.04 64bit host

[Sasa Paporovic]

I am on Ubuntu12.04 64bit updated to 7.4.2012.

On this platform I am using qemu-kvm1.0 with virt-manager(?->latest).

I have had runned a Ubuntu12.04 guest in this configuration. On newstart sequence to finishing updates of the guest(new kernel verison) the guest vm crashed.

A .crash file was gathered in /var/crash/ for this, but apport failed to report it and crashed itself:

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/975832

The .crash file of the qemu-kvm issue is above 600MB of size, which may be the cause for apport failing.

In kernel log:

Apr 7 11:30:38 userhost kernel: [ 4002.056049] CE: hpet increased min_delta_ns to 20113 nsec
Apr 7 11:30:38 userhost kernel: [ 4002.056049] CE: hpet increased min_delta_ns to 30169 nsec
Apr 7 11:30:38 userhost kernel: [ 4002.236057] CE: hpet increased min_delta_ns to 45253 nsec
Apr 7 11:30:41 userhost kernel: [ 4004.864051] CE: hpet increased min_delta_ns to 67879 nsec
Apr 7 11:34:07 userhost kernel: [ 4210.680024] CE: hpet increased min_delta_ns to 101818 nsec
Apr 7 11:34:07 userhost kernel: [ 4210.896493] CE: hpet increased min_delta_ns to 152727 nsec
Apr 7 11:34:08 userhost kernel: [ 4211.656321] CE: hpet increased min_delta_ns to 229090 nsec
Apr 7 11:34:08 userhost kernel: [ 4212.276005] CE: hpet increased min_delta_ns to 343635 nsec
Apr 7 11:34:09 userhost kernel: [ 4212.860016] CE: hpet increased min_delta_ns to 515452 nsec
Apr 7 11:40:20 userhost kernel: [ 4583.899285] CE: hpet increased min_delta_ns to 773178 nsec
Apr 7 11:40:23 userhost kernel: [ 4586.516174] CE: hpet increased min_delta_ns to 1159767 nsec
Apr 7 11:41:57 userhost kernel: [ 4681.220137] INFO: task kvm:4823 blocked for more than 120 seconds.
Apr 7 11:41:57 userhost kernel: [ 4681.220146] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 7 11:41:57 userhost kernel: [ 4681.220152] kvm D 0000000000000004 0 4823 1 0x00000000
Apr 7 11:41:57 userhost kernel: [ 4681.220164] ffff8802c2333cc8 0000000000000086 0000000000000000 ffffffffffffffe0
Apr 7 11:41:57 userhost kernel: [ 4681.220177] ffff8802c2333fd8 ffff8802c2333fd8 ffff8802c2333fd8 0000000000013780
Apr 7 11:41:57 userhost kernel: [ 4681.220188] ffff880265e216f0 ffff88030b8b2de0 ffff88030b8b2de0 ffff88030781f800
Apr 7 11:41:57 userhost kernel: [ 4681.220198] Call Trace:
Apr 7 11:41:57 userhost kernel: [ 4681.220213] [<ffffffff8165a56f>] schedule+0x3f/0x60
Apr 7 11:41:57 userhost kernel: [ 4681.220224] [<ffffffff8106b7d5>] exit_mm+0x85/0x130
Apr 7 11:41:57 userhost kernel: [ 4681.220233] [<ffffffff8106b9ee>] do_exit+0x16e/0x420
Apr 7 11:41:57 userhost kernel: [ 4681.220272] [<ffffffffa04a7b6b>] ? kvm_vcpu_block+0x9b/0xb0 [kvm]
Apr 7 11:41:57 userhost kernel: [ 4681.220284] [<ffffffff8107a18a>] ? __dequeue_signal+0x6a/0xb0
Apr 7 11:41:57 userhost kernel: [ 4681.220293] [<ffffffff8107a42b>] ? recalc_sigpending+0x1b/0x50
Apr 7 11:41:57 userhost kernel: [ 4681.220302] [<ffffffff8106be44>] do_group_exit+0x44/0xa0
Apr 7 11:41:57 userhost kernel: [ 4681.220310] [<ffffffff8107cccc>] get_signal_to_deliver+0x21c/0x420
Apr 7 11:41:57 userhost kernel: [ 4681.220321] [<ffffffff81013865>] do_signal+0x45/0x130
Apr 7 11:41:57 userhost kernel: [ 4681.220331] [<ffffffff81055fdd>] ? set_next_entity+0xad/0xd0
Apr 7 11:41:57 userhost kernel: [ 4681.220340] [<ffffffff81189cfa>] ? do_vfs_ioctl+0x8a/0x340
Apr 7 11:41:57 userhost kernel: [ 4681.220347] [<ffffffff81659f1c>] ? __schedule+0x3cc/0x6f0
Apr 7 11:41:57 userhost kernel: [ 4681.220355] [<ffffffff81013b15>] do_notify_resume+0x65/0x80
Apr 7 11:41:57 userhost kernel: [ 4681.220366] [<ffffffff8118a02b>] ? sys_ioctl+0x7b/0xa0
Apr 7 11:41:57 userhost kernel: [ 4681.220374] [<ffffffff81664d50>] int_signal+0x12/0x17
Apr 7 11:41:57 userhost kernel: [ 4681.220382] INFO: task kvm:4824 blocked for more than 120 seconds.
Apr 7 11:41:57 userhost kernel: [ 4681.220387] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 7 11:41:57 userhost kernel: [ 4681.220392] kvm D 0000000000000002 0 4824 1 0x00000000
Apr 7 11:41:57 userhost kernel: [ 4681.220401] ffff88030952fcc8 0000000000000086 0000000000000000 ffffffffffffffe0
Apr 7 11:41:57 userhost kernel: [ 4681.220412] ffff88030952ffd8 ffff88030952ffd8 ffff88030952ffd8 0000000000013780
Apr 7 11:41:57 userhost kernel: [ 4681.220422] ffff880301042de0 ffff8802edc216f0 ffff8802edc216f0 ffff88030781f800

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: qemu-kvm 1.0+noroms-0ubuntu10
ProcVersionSignature: Ubuntu 3.2.0-22.35-generic 3.2.14
Uname: Linux 3.2.0-22-generic x86_64
ApportVersion: 2.0-0ubuntu4
Architecture: amd64
Date: Sat Apr 7 11:47:30 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64+mac (20120328)
MachineType: MICRO-STAR INTERNATIONAL CO.,LTD MS-7596
ProcEnviron:
 PATH=(custom, no username)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-22-generic root=UUID=00ec9d51-a52f-4879-b208-5bf9136b7e49 ro quiet splash vt.handoff=7
SourcePackage: qemu-kvm
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/03/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V1.8
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 760GM -E51 (MS-7596)
dmi.board.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.8:bd09/03/2010:svnMICRO-STARINTERNATIONALCO.,LTD:pnMS-7596:pvr1.0:rvnMICRO-STARINTERNATIONALCO.,LTD:rn760GM-E51(MS-7596):rvr1.0:cvnMICRO-STARINTERNATIONALCO.,LTD:ct3:cvr1.0:
dmi.product.name: MS-7596
dmi.product.version: 1.0
dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO.,LTD

[Serge Hallyn (serge-hallyn)]

Thanks for taking the time to report this bug.

I will mark it as also affecting the kernel.

Have you had any other instabilities, beside qemu-kvm, on this system?

[Serge Hallyn (serge-hallyn)]

Certainly looks like the kvm module was deadlocked on exit,

Apr 7 11:41:57 userhost kernel: [ 4681.220272] [<ffffffffa04a7b6b>] ? kvm_vcpu_block+0x9b/0xb0 [kvm]

[Sasa Paporovic (melchiaros)]

Q:Have you had any other instabilities, beside qemu-kvm, on this system?

A:No.

[Sasa Paporovic (melchiaros)]

I have had runned two other vm is parallel.

A Ubuntu11.10 vm -> running uck for remastering 11.10.iso final -> heavy harddrive load -> no errors
A Windows7Sp1en_debug vm -> installing ultimate edition -> heavy harddrive load -> no errors

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Sasa Paporovic (melchiaros)]

Yes, kernelbugs are all arround.

I have not reproduced it with the Ubuntu 3.2.0-22.35-generic 3.2.14, so a not reproducibility with the every latest says nothing about if the bug is still there or not.

A vm can have a high number of different sates which I could not controll in detail.

So retesting requests on virtualisation bugs where it is not absolutely sure that they are 100% reproducible crashers are useless.

(And mostly the are not deterministic ones.)

[Serge Hallyn (serge-hallyn)]

As soon as I have amd hardware available I'll try a series of guest updates to reproduce.

[Serge Hallyn (serge-hallyn)]

I can't reproduce on amd hardware.