Red Hat Bugzilla – Bug 963966
[abrt] WARNING: at include/linux/kref.h:42 handle_tx+0x5f5/0x630 [vhost_net]()
Last modified: 2013-05-25 15:03:38 EDT
Additional info: reporter: libreport-2.1.4 WARNING: at include/linux/kref.h:42 handle_tx+0x5f5/0x630 [vhost_net]() Hardware name: MacBookPro4,1 Modules linked in: vhost_net tun macvtap macvlan fuse ebtable_nat ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables rfcomm ip6table_filter ip6_tables bnep nls_utf8 hfsplus b43 bcma acpi_cpufreq mac80211 mperf coretemp kvm_intel kvm joydev snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media cfg80211 bcm5974 btusb snd_seq_device iTCO_wdt iTCO_vendor_support snd_pcm bluetooth snd_page_alloc applesmc input_polldev microcode i2c_i801 snd_timer lpc_ich rfkill mfd_core ssb sky2 mmc_core snd soundcore apple_bl nouveau mxm_wmi firewire_ohci wmi i2c_algo_bit drm_kms_helper firewire_core ttm crc_itu_t drm i2c_core video uinput Pid: 2872, comm: vhost-2871 Not tainted 3.9.2-301.fc19.x86_64 #1 Call Trace: [<ffffffff8105cd86>] warn_slowpath_common+0x66/0x80 [<ffffffff8105ce5a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa06c9e85>] handle_tx+0x5f5/0x630 [vhost_net] [<ffffffffa06c9ef5>] handle_tx_kick+0x15/0x20 [vhost_net] [<ffffffffa06c681d>] vhost_worker+0xed/0x190 [vhost_net] [<ffffffffa06c6730>] ? __vhost_add_used_n+0x100/0x100 [vhost_net] [<ffffffff81080340>] kthread+0xc0/0xd0 [<ffffffff81080280>] ? insert_kthread_work+0x40/0x40 [<ffffffff8164dc6c>] ret_from_fork+0x7c/0xb0 [<ffffffff81080280>] ? insert_kthread_work+0x40/0x40 Potential duplicate: bug 918015
Created attachment 749080 [details] File: dmesg
This is triggered by a qemu-kvm session in Virtual Machine Manager. So far it seems issuing a reboot or poweroff command while ssh'd into the VM triggers this.
Created attachment 749131 [details] dmesg 3.10.0-0.rc1.git5.1.fc20.x86_64 Same problem occurs with kernel 3.10.0-0.rc1.git5.1.fc20.x86_64. I can consistently reproduce by starting a qemu-kvm session with Virtual Machine Manager, ssh'ing into the VM, and issuing a reboot command. Host system: 3.10.0-0.rc1.git5.1.fc20.x86_64 libvirt-1.0.5-3.fc19.x86_64 virt-manager-0.10.0-0.4.gitb68faac8.fc19.noarch VM system uses kernel 3.9.0-301.fc19.x86_64
Host system: qemu-kvm-1.4.1-2.fc19.x86_64 libvirt-daemon-driver-qemu-1.0.5-3.fc19.x86_64 qemu-guest-agent-1.4.1-2.fc19.x86_64 qemu-common-1.4.1-2.fc19.x86_64 ipxe-roms-qemu-20130103-1.git717279a.fc19.noarch qemu-system-x86-1.4.1-2.fc19.x86_64 qemu-img-1.4.1-2.fc19.x86_64
Created attachment 749132 [details] dmesg 3.10.0-0.rc1.git5.1.fc20.x86_64 part 2 previous 3.10-0 dmesg ends at [ 961.566821] This continues on with more info, same boot.
This is probably a duplicate of 954181
Regression testing: The above description and comments through #6 is F19 beta TC on qemu-kvm on F19 with all current updates on baremetal. If I replace F19 with F18 fully updated on baremetal, but keep the F19 qemu, I cannot reproduce the problem with kernel 3.9.2-200.fc18.x86_64. So I wonder if there's something new in F19 qemu-kvm or libvirt on F19 that's triggering some latent bug in the kernel that wasn't previously being poked with F18 versions of qemu-kvm and libvirt. F18 host: virt-manager-0.9.5-1.fc18.noarch qemu-img-1.2.2-11.fc18.x86_64 qemu-kvm-1.2.2-11.fc18.x86_64 ipxe-roms-qemu-20120328-2.gitaac9718.fc18.noarch libvirt-daemon-driver-qemu-0.10.2.4-1.fc18.x86_64 qemu-common-1.2.2-11.fc18.x86_64 qemu-system-x86-1.2.2-11.fc18.x86_64
*** This bug has been marked as a duplicate of bug 954181 ***