Bug 988606 - general protection fault: 0000 [#1] SMP while running VM using KVM/libvirt
Summary: general protection fault: 0000 [#1] SMP while running VM using KVM/libvirt
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-25 23:44 UTC by Daniel Rowe
Modified: 2013-11-26 02:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-08 16:49:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Daniel Rowe 2013-07-25 23:44:35 UTC
Description of problem:

There seem to be an issue on Fedora 19 and running KVM VMs. We use fedora and libvirt to run VM on Dell server hardware. 

On a couple of different machines this kernel oops has happened which causes the VM to get completely stuck. Note I have replicated this on a workstation as well as the server hardware so does not appear to be a particular hardware issue. 

The VM appears to drop its network connection and get stuck in this state. On the host the oops appears and then the VM can not be destroyed and gets stuck. This seem to be on Windows 7 guest and Windows 2008R2 Guests runing the latest SPICE 0.59 guest tools.

[689856.514315] general protection fault: 0000 [#1] SMP 
[689856.518392] Modules linked in: nfsv3 nfs_acl nfsv4 auth_rpcgss nfs lockd sunrpc dns_resolver fscache vhost_net macvtap macvlan ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack acpi_cpufreq mperf coretemp kvm_intel iTCO_wdt iTCO_vendor_support ses dcdbas kvm crc32_pclmul crc32c_intel ghash_clmulni_intel i7core_edac edac_core lpc_ich microcode serio_raw bnx2 enclosure mfd_core acpi_power_meter mgag200 i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas
[689856.544172] CPU 5 
[689856.544302] Pid: 30443, comm: vhost-30442 Tainted: G          I  3.9.9-302.fc19.x86_64 #1 Dell Inc. PowerEdge T610/09CGW2
[689856.560087] RIP: 0010:[<ffffffff8113ccaa>]  [<ffffffff8113ccaa>] put_page+0xa/0x60
[689856.568780] RSP: 0018:ffff8805e41e7c78  EFLAGS: 00010206
[689856.577557] RAX: ffff880036fd16c0 RBX: 0000000000000013 RCX: 0000000000000003
[689856.586864] RDX: 0000000000000150 RSI: 0000000000000246 RDI: ff1d7d0001000000
[689856.596284] RBP: ffff8805e41e7c80 R08: 0000000000000003 R09: 0000000000000010
[689856.605924] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88060d3cb500
[689856.615698] R13: ffffffffa014efd4 R14: 000000000000000c R15: ffff88060d3cb500
[689856.625546] FS:  0000000000000000(0000) GS:ffff880617c40000(0000) knlGS:0000000000000000
[689856.635743] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[689856.646078] CR2: 00000000d79c0270 CR3: 0000000bfe78a000 CR4: 00000000000027e0
[689856.656815] DR0: 0000000000000001 DR1: 0000000000000002 DR2: 0000000000000001
[689856.667703] DR3: 000000000000000a DR6: 00000000ffff0ff0 DR7: 0000000000000400
[689856.678628] Process vhost-30442 (pid: 30443, threadinfo ffff8805e41e6000, task ffff88066c544650)
[689856.689965] Stack:
[689856.701233]  0000000000000013 ffff8805e41e7ca0 ffffffff8152d0a7 ffff88060d3cb500
[689856.713235]  ffff88060d3cb500 ffff8805e41e7cb8 ffffffff8152d13a ffff88076bc00800
[689856.725357]  ffff8805e41e7ce0 ffffffff8152d202 ffff88076bc00800 000000000000f572
[689856.737718] Call Trace:
[689856.750069]  [<ffffffff8152d0a7>] skb_release_data+0x87/0x100
[689856.762732]  [<ffffffff8152d13a>] __kfree_skb+0x1a/0xb0
[689856.775246]  [<ffffffff8152d202>] kfree_skb+0x32/0x90
[689856.787878]  [<ffffffffa014efd4>] tun_get_user+0x724/0x810 [tun]
[689856.800813]  [<ffffffffa014f117>] tun_sendmsg+0x57/0x80 [tun]
[689856.813746]  [<ffffffffa0249a78>] handle_tx+0x1c8/0x640 [vhost_net]
[689856.826838]  [<ffffffffa0249f25>] handle_tx_kick+0x15/0x20 [vhost_net]
[689856.840134]  [<ffffffffa024681d>] vhost_worker+0xed/0x190 [vhost_net]
[689856.853634]  [<ffffffffa0246730>] ? __vhost_add_used_n+0x100/0x100 [vhost_net]
[689856.867394]  [<ffffffff810802a0>] kthread+0xc0/0xd0
[689856.881309]  [<ffffffff810801e0>] ? insert_kthread_work+0x40/0x40
[689856.895446]  [<ffffffff8164f26c>] ret_from_fork+0x7c/0xb0
[689856.909735]  [<ffffffff810801e0>] ? insert_kthread_work+0x40/0x40
[689856.924224] Code: 00 00 01 75 f3 e9 b6 fe ff ff be 47 01 00 00 48 c7 c7 47 53 9d 81 e8 76 00 f2 ff e9 a0 fe ff ff 90 66 66 66 66 90 55 48 89 e5 53 <48> f7 07 00 c0 00 00 48 89 fb 75 30 8b 47 1c 85 c0 74 16 f0 ff 
[689856.955763] RIP  [<ffffffff8113ccaa>] put_page+0xa/0x60
[689856.971599]  RSP <ffff8805e41e7c78>
[689857.094817] ---[ end trace a840c2e8a50b914c ]---

Comment 1 Josh Boyer 2013-09-18 20:25:38 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 2 Josh Boyer 2013-10-08 16:49:15 UTC
This was fixed with an update some time ago.

Comment 3 Michael Gregg 2013-11-26 02:51:54 UTC
I was hitting this problem in 3.9.5.

Upgrading to 3.11.9-200 seems to have resolved my problems.


Note You need to log in before you can comment on or make changes to this bug.