virt

virt@lists.centos.org

2 participants
1613 discussions

Stability issues since moving to 4.6 - Kernel paging request bug + VM left in null state
by Nathan March 15 Nov '17

15 Nov '17

Since moving from 4.4 to 4.6, I've been seeing an increasing number of stability issues on our hypervisors. I'm not clear if there's a singular root cause here, or if I'm dealing with multiple bugs. One of the more common ones I've seen, is a VM on shutdown will remain in the null state and a kernel bug is thrown: xen001 log # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 6144 24 r----- 6639.7 (null) 3 0 1 --pscd 36.3 [89920.839074] BUG: unable to handle kernel paging request at ffff88020ee9a000 [89920.839546] IP: [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.839933] PGD 2008067 [89920.840022] PUD 17f43f067 [89920.840390] PMD 1e0976067 [89920.840469] PTE 0 [89920.840833] [89920.841123] Oops: 0000 [#1] SMP [89920.841417] Modules linked in: ebt_ip ebtable_filter ebtables arptable_filter arp_tables bridge xen_pciback xen_gntalloc nfsd auth_rpcgss nfsv3 nfs_acl nfs fscache lockd sunrpc grace 8021q mrp garp stp llc bonding xen_acpi_processor blktap xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd dcdbas fjes pcspkr ipmi_devintf ipmi_si ipmi_msghandler joydev i2c_i801 i2c_smbus lpc_ich shpchp mei_me mei ioatdma ixgbe mdio igb dca ptp pps_core uas usb_storage wmi ttm [89920.847080] CPU: 4 PID: 1471 Comm: loop6 Not tainted 4.9.58-29.el6.x86_64 #1 [89920.847381] Hardware name: Dell Inc. PowerEdge C6220/03C9JJ, BIOS 2.7.1 03/04/2015 [89920.847893] task: ffff8801b75e0700 task.stack: ffffc900460e0000 [89920.848192] RIP: e030:[<ffffffff81430922>] [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.848783] RSP: e02b:ffffc900460e3b20 EFLAGS: 00010246 [89920.849081] RAX: ffff88018916d000 RBX: ffff8801b75e0700 RCX: 0000000000000200 [89920.849384] RDX: 0000000000000000 RSI: ffff88020ee9a000 RDI: ffff88018916d000 [89920.849686] RBP: ffffc900460e3b38 R08: ffff88011da9fcf8 R09: 0000000000000002 [89920.849989] R10: ffff88019535bddc R11: ffffea0006245b5c R12: 0000000000001000 [89920.850294] R13: ffff88018916e000 R14: 0000000000001000 R15: ffffc900460e3b68 [89920.850605] FS: 00007fb865c30700(0000) GS:ffff880204b00000(0000) knlGS:0000000000000000 [89920.851118] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [89920.851418] CR2: ffff88020ee9a000 CR3: 00000001ef03b000 CR4: 0000000000042660 [89920.851720] Stack: [89920.852009] ffffffff814375ca ffffc900460e3b38 ffffc900460e3d08 ffffc900460e3bb8 [89920.852821] ffffffff814381c5 ffffc900460e3b68 ffffc900460e3d08 0000000000001000 [89920.853633] ffffc900460e3d88 0000000000000000 0000000000001000 ffffea0000000000 [89920.854445] Call Trace: [89920.854741] [<ffffffff814375ca>] ? memcpy_from_page+0x3a/0x70 [89920.855043] [<ffffffff814381c5>] iov_iter_copy_from_user_atomic+0x265/0x290 [89920.855354] [<ffffffff811cf633>] generic_perform_write+0xf3/0x1d0 [89920.855673] [<ffffffff8101e39a>] ? xen_load_tls+0xaa/0x160 [89920.855992] [<ffffffffc025cf2b>] nfs_file_write+0xdb/0x200 [nfs] [89920.856297] [<ffffffff81269062>] vfs_iter_write+0xa2/0xf0 [89920.856599] [<ffffffff815fa365>] lo_write_bvec+0x65/0x100 [89920.856899] [<ffffffff815fc375>] do_req_filebacked+0x195/0x300 [89920.857202] [<ffffffff815fc53b>] loop_queue_work+0x5b/0x80 [89920.857505] [<ffffffff810c6898>] kthread_worker_fn+0x98/0x1b0 [89920.857808] [<ffffffff818d9dca>] ? schedule+0x3a/0xa0 [89920.858108] [<ffffffff818ddbb6>] ? _raw_spin_unlock_irqrestore+0x16/0x20 [89920.858411] [<ffffffff810c6800>] ? kthread_probe_data+0x40/0x40 [89920.858713] [<ffffffff810c63f5>] kthread+0xe5/0x100 [89920.859014] [<ffffffff810c6310>] ? __kthread_init_worker+0x40/0x40 [89920.859317] [<ffffffff818de2d5>] ret_from_fork+0x25/0x30 [89920.859615] Code: 81 f3 00 00 00 00 e9 1e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 [89920.864410] RIP [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.864749] RSP <ffffc900460e3b20> [89920.865021] CR2: ffff88020ee9a000 [89920.865294] ---[ end trace b77d2ce5646284d1 ]--- Wondering if anyone has advice on how to troubleshoot the above, or might have some insight into that the issue could be? This hypervisor was only up for a day, had almost no VMs running on it since boot, I booted a single windows test VM which BSOD'ed and then this happened. This is on xen 4.6.6-4.el6 with 4.9.58-29.el6.x86_64. I see these issues across a wide number of systems with from both Dell and Supermicro, although we run the same Intel x540 10gb nic's in each system with the same netapp nfs backend storage. Cheers, Nathan

3 3

Live migration haswell, broadwell
by T.Weyergraf 14 Nov '17

14 Nov '17

Hi I wonder, if live migration (back and forth) is possible on mixed Haswell (Xeon V3) and Broadwell (Xeon V4) installations. The only notable difference between the two is apparently a working TSX implementation on V4, which got disabled on V3 due to bugs. The rest (VMCS-shadowing, posted interrupts) should not apply to our environment, as we do not run nested-vmx nor device-passthrough on our Xen servers. Now, I found no sane way to disable TSX on a given system but I cannot rule out, that some (Linux-)software, such as Postgres will use them eventually. Also, I have a hard time trying to assess, if TSX can be disabled on V4 to enable seamless migration. Any hint would be greately appreciated.

2 1

Crash in network stack under Xen
by Sarah Newman 13 Nov '17

13 Nov '17

Hi, We had a potentially network related crash on a dom0 with Linux 4.9.39 / Xen 4.8 and as of today I can't find any fixes in stable/linux-4.9.y, xen/staging-4.8, or CPU microcode updates that look like a smoking gun. I can't rule out that it's Xen related. The backtraces are: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:1473 inet_gro_complete+0xbb/0xd0 Call Trace: <IRQ> dump_stack+0x63/0x8e __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 inet_gro_complete+0xbb/0xd0 napi_gro_complete+0x73/0xa0 napi_gro_flush+0x5f/0x80 napi_complete_done+0x6a/0xb0 igb_poll+0x38d/0x720 [igb] ? igb_msix_ring+0x2e/0x40 [igb] ? __handle_irq_event_percpu+0x4b/0x1a0 net_rx_action+0x158/0x360 __do_softirq+0xd1/0x283 irq_exit+0xe9/0x100 xen_evtchn_do_upcall+0x35/0x50 xen_do_hypervisor_callback+0x1e/0x40 <EOI> ? xen_hypercall_sched_op+0xa/0x20 ? xen_hypercall_sched_op+0xa/0x20 ? xen_safe_halt+0x10/0x20 ? default_idle+0x1e/0xd0 ? arch_cpu_idle+0xf/0x20 ? default_idle_call+0x2c/0x40 ? cpu_startup_entry+0x1ac/0x240 ? rest_init+0x77/0x80 ? start_kernel+0x4a7/0x4b4 ? set_init_arg+0x55/0x55 ? x86_64_start_reservations+0x24/0x26 ? xen_start_kernel+0x555/0x561 general protection fault: 0000 [#1] SMP Call Trace: <IRQ> ? napi_gro_complete+0x5e/0xa0 skb_release_all+0x24/0x30 kfree_skb+0x32/0x90 napi_gro_complete+0x5e/0xa0 napi_gro_flush+0x5f/0x80 napi_complete_done+0x6a/0xb0 igb_poll+0x38d/0x720 [igb] ? igb_msix_ring+0x2e/0x40 [igb] ? __handle_irq_event_percpu+0x4b/0x1a0 net_rx_action+0x158/0x360 __do_softirq+0xd1/0x283 irq_exit+0xe9/0x100 xen_evtchn_do_upcall+0x35/0x50 xen_do_hypervisor_callback+0x1e/0x40 <EOI> ? xen_hypercall_sched_op+0xa/0x20 ? xen_hypercall_sched_op+0xa/0x20 ? xen_safe_halt+0x10/0x20 ? default_idle+0x1e/0xd0 ? arch_cpu_idle+0xf/0x20 ? default_idle_call+0x2c/0x40 ? cpu_startup_entry+0x1ac/0x240 ? rest_init+0x77/0x80 ? start_kernel+0x4a7/0x4b4 ? set_init_arg+0x55/0x55 ? x86_64_start_reservations+0x24/0x26 ? xen_start_kernel+0x555/0x561 RIP skb_release_data+0x73/0xf0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. If anyone has had a similar backtrace or knows of a potential fix please respond. This server has ECC and there were no ECC or other errors in the BIOS event log, nor were there any indications of any problems in the serial console log leading up to the warning. This particular server had an uptime of about a month and a half, and so far we've had this error exactly once across all our servers since switching to 4.9.39 in August, so I don't think it's going to be easy to reproduce. --- It looks to me like in the first backtrace, this check from inet_gro_complete failed: ops = rcu_dereference(inet_offloads[proto]); Which I'm guessing means the packet didn't have a valid layer 4 protocol definition, or we don't have that protocol enabled. Then when attempting to handle that failure there was a GPF, I believe by accessing invalid data in shinfo->frag_list . "skb_release_data+0x73" is in __read_once_size, which I think is generated by "kfree_skb: if (likely(atomic_read(&skb->users) == 1))" . --Sarah

2 1

Non Marketplace AMI for 1708
by Andrew Jeffree 13 Nov '17

13 Nov '17

Hi, Currently, there are some images that are published outside of the AWS Market Place [0] for 1703 are there plans to have updated ones available for 1708? Kind Regards, Andrew [0] - https://wiki.centos.org/Cloud/AWS#head-78d1e3a4e6ba5c5a3847750d88266916ffe6…

1 0

CentOS 7 x86_64 with Updates HVM not enabled for new c5.* instances, ENA support tagged incorrectly
by Chris Merrett 10 Nov '17

10 Nov '17

Hi, We’ve been looking to try out the c5.* instances with the latest AMI for the aforementioned image within us-east-1, but this will fail due to both the allowed instance list not containing c5.* and the ENA support flag being set to false. ENA support shipped with CentOS 7.4 and should now be fine to be enabled within the AMI metadata, which judging by a similar thread in July this year (https://lists.centos.org/pipermail/centos-virt/2017-July/005592.html <https://lists.centos.org/pipermail/centos-virt/2017-July/005592.html>) could also enable support for the c5.* instances where ENA is a requirement. Would it be possible to enable ENA support for this image, as well as enable support for c5.* instances if that doesn’t happen automatically? Thanks for everything, your work is very much appreciated. Regards, Chris Merrett

1 0

OT?: NetBSD domU on linux dom0 (XSA-240?)
by Tru Huynh 06 Nov '17

06 Nov '17

Hi No 1st hand experience, just passing the information... If some of you are hosting NetBSD on Xenserver, that might impact: http://mail-index.netbsd.org/port-xen/2017/10/23/msg009097.html and the work around listed in http://mail-index.netbsd.org/port-xen/2017/10/23/msg009098.html "I guess this is the patch from XSA-240, you need to boot with pv-linear-pt=true on the Xen command line" Cheers Tru -- Tru Huynh http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Install virtual guest from console
by C. L. Martinez 31 Oct '17

31 Oct '17

HI all, Is it possible to install a virtual guest (FreeBSD and OpenBSD mainly) from kvm host's console? I have tried to do some search about this but I haven't found anything about it. My idea is to launch "virsh start guest1" and inmediately "virsh console guest1", but it doesn't works until serial console is configured inside guest .... Any tip? Thanks.

2 1

Fwd: Network interface regression on F26 VM after 4.13/4.12 kernel update
by Philip Prindeville 27 Oct '17

27 Oct '17

I did not hear back on this posting so I figured I was addressing the wrong audience. Maybe someone on the host-side better understands how the 4.12 kernel is interacting with KVM. Thanks, -Philip > Begin forwarded message: > > From: Philip Prindeville <philipp_subx(a)redfish-solutions.com> > Subject: Network interface regression on F26 VM after 4.13/4.12 kernel update > Date: October 26, 2017 at 4:16:53 PM MDT > To: devel(a)lists.fedoraproject.org > Reply-To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> > > I was running F25 (4.10) on a VM inside KVM/Qemu/libvirt on CentOS 7.3 (updated). > > Then I upgraded it (via dnf system-upgrade) to F26 and 4.11 and it was still working well, as I recall. > > Then I upgraded it again to 4.13 and now I’m seeing flakiness in the network: the NIC will randomly come up and go down. > > Right now I’m seeing: > > $ ip link show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: ens3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 > link/ether 52:54:00:29:01:5b brd ff:ff:ff:ff:ff:ff > $ > > my messages file shows: > > Oct 26 14:25:51 son-of-builder kernel: igbvf 0000:00:03.0: Link is Down > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.0757] device (ens3): state change: activated -> unavailable (reason 'carrier-changed', internal state 'managed') > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=filter family=2 entries=86 > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.0932] dhcp4 (ens3): canceled DHCP transaction, DHCP client pid 8008 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=nat family=2 entries=52 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=mangle family=2 entries=40 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=raw family=2 entries=29 > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.0933] dhcp4 (ens3): state changed bound -> done > Oct 26 14:25:56 son-of-builder avahi-daemon[756]: Withdrawing address record for 192.168.1.56 on ens3. > Oct 26 14:25:56 son-of-builder avahi-daemon[756]: Leaving mDNS multicast group on interface ens3.IPv4 with address 192.168.1.56. > Oct 26 14:25:56 son-of-builder avahi-daemon[756]: Interface ens3.IPv4 no longer relevant for mDNS. > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:4 'connectivity-change': new request (5 scripts) > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:4 'connectivity-change': start running ordered scripts... > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=filter family=10 entries=87 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=nat family=10 entries=52 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=mangle family=10 entries=40 > Oct 26 14:25:56 son-of-builder audit: NETFILTER_CFG table=raw family=10 entries=30 > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.1140] manager: NetworkManager state is now CONNECTED_LOCAL > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.1145] manager: NetworkManager state is now DISCONNECTED > Oct 26 14:25:56 son-of-builder NetworkManager[824]: <info> [1509049556.1256] policy: set-hostname: set hostname to 'localhost.localdomain' (no default device) > Oct 26 14:25:56 son-of-builder systemd-hostnamed[8026]: Changed host name to 'localhost.localdomain' > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:5 'down' [ens3]: new request (5 scripts) > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:6 'hostname': new request (5 scripts) > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:5 'down' [ens3]: start running ordered scripts... > Oct 26 14:25:56 son-of-builder nm-dispatcher[8018]: req:6 'hostname': start running ordered scripts... > Oct 26 14:26:06 son-of-builder audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Oct 26 14:26:21 son-of-builder NetworkManager[824]: <info> [1509049581.0808] connectivity: (ens3) timed out > Oct 26 14:26:21 son-of-builder dbus-daemon[761]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.10' (uid=0 pid=824 comm="/usr/sbin/NetworkManager --no-daemon " label="system_u:system_r:NetworkManager_t:s0") > Oct 26 14:26:21 son-of-builder systemd[1]: Starting Network Manager Script Dispatcher Service... > Oct 26 14:26:21 son-of-builder dbus-daemon[761]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' > Oct 26 14:26:21 son-of-builder systemd[1]: Started Network Manager Script Dispatcher Service. > Oct 26 14:26:21 son-of-builder audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Oct 26 14:26:21 son-of-builder nm-dispatcher[8169]: req:1 'connectivity-change': new request (5 scripts) > Oct 26 14:26:21 son-of-builder nm-dispatcher[8169]: req:1 'connectivity-change': start running ordered scripts... > Oct 26 14:26:26 son-of-builder audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Oct 26 14:26:31 son-of-builder audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success’ > > > Before the network configuration used to be rock-solid. I’m running on a Xeon D-1548 SoC with an on-chip X552/557 (ixgbe.ko) and an off-chip i350 (igb.ko) quad-NIC. In this case, I’m using the first port of the i350. > > The VM’s XML is unchanged, as it was previously (while things were working reliably): > > <interface type='network'> > <mac address='52:54:00:29:01:5b'/> > <source network='hostdev-net0'/> > <model type='virtio'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> > </interface> > > I’ve also tried “e1000”, “igb”, and “rtl8139” as the model type, with no appreciable difference since this problem started. > > Just did a quick check: reinstalling 4.11.10-300 seems to restore functionality. > > It was broken when I tried 4.12.11-300 as well. > > -Philip

1 0

Crash in CentOS 7 kernel-3.10.0-514.16.1.el7.x86_64 in Xen PV mode
by Sarah Newman 24 Oct '17

24 Oct '17

I experienced a bug that is likely the same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350373 . Commit b7dd0e350e0bd4c0fddcc9b8958342700b00b168 , which is supposed to fix it, doesn't appear in this kernel and doesn't apply cleanly either. Is there any point in trying to backport the patch? The backtrace is as follows: [ 32.304666] ------------[ cut here ]------------ [ 32.304679] kernel BUG at arch/x86/kernel/paravirt.c:252! [ 32.304683] invalid opcode: 0000 [#1] SMP [ 32.304687] Modules linked in: ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter intel_powerclamp coretemp pcspkr ip_tables ext4 mbcache jbd2 xen_netfront xen_blkfront crc32c_intel [ 32.304734] CPU: 0 PID: 3901 Comm: dracut Not tainted 3.10.0-514.16.1.el7.x86_64 #1 [ 32.304739] task: ffff880002598000 ti: ffff88001b728000 task.ti: ffff88001b728000 [ 32.304743] RIP: e030:[<ffffffff8167eb81>] [<ffffffff8167eb81>] enter_lazy.part.0+0x4/0x6 [ 32.304755] RSP: e02b:ffff88001f803aa8 EFLAGS: 00010002 [ 32.304758] RAX: 0000000000000001 RBX: ffff88001eacd640 RCX: 00003ffffffff000 [ 32.304761] RDX: ffff880000000640 RSI: ffffc900000c8000 RDI: 0000000000000001 [ 32.304765] RBP: ffff88001f803aa8 R08: ffff88001f803b78 R09: ffffffff813d50f9 [ 32.304771] R10: ffff88001e801e00 R11: ffffea0000093dc0 R12: ffffc900000c9000 [ 32.304777] R13: ffffc900000c8000 R14: 0000000000000000 R15: ffff88001d150340 [ 32.304787] FS: 00007f64425b0740(0000) GS:ffff88001f800000(0000) knlGS:0000000000000000 [ 32.304796] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 32.304801] CR2: 00000000006de2c8 CR3: 000000001b405000 CR4: 0000000000002660 [ 32.304807] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 32.304813] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 32.304818] Stack: [ 32.304823] ffff88001f803ab8 ffffffff81061857 ffff88001f803b60 ffffffff811b1fe2 [ 32.304833] ffffc900000c8fff ffffc900000c9000 ffffffff819bac90 ffffc900000c8fff [ 32.304843] ffffc900000c9000 ffff88001eacb000 ffffffff810206b0 0000000000000000 [ 32.304854] Call Trace: [ 32.304858] <IRQ> [ 32.304861] [<ffffffff81061857>] paravirt_enter_lazy_mmu+0x27/0x30 [ 32.304879] [<ffffffff811b1fe2>] apply_to_page_range+0x282/0x460 [ 32.304888] [<ffffffff810206b0>] ? map_pte_fn+0x60/0x60 [ 32.304894] [<ffffffff810207fb>] arch_gnttab_map_status+0x3b/0x70 [ 32.304904] [<ffffffff813d5176>] gnttab_map_frames_v2+0xd6/0x150 [ 32.304910] [<ffffffff813d5291>] gnttab_map+0xa1/0x140 [ 32.304917] [<ffffffff813d5430>] get_free_entries+0x100/0x2e0 [ 32.304923] [<ffffffff813d56d5>] gnttab_alloc_grant_references+0x15/0x30 [ 32.304933] [<ffffffffa000bd4f>] do_blkif_request+0x6bf/0x8a0 [xen_blkfront] [ 32.304945] [<ffffffff812eb0e2>] ? __freed_request+0x92/0xa0 [ 32.304951] [<ffffffff812eb6e3>] __blk_run_queue+0x33/0x40 [ 32.304957] [<ffffffff812eb719>] blk_start_queue+0x29/0x40 [ 32.304964] [<ffffffffa000bf51>] kick_pending_request_queues+0x21/0x30 [xen_blkfront] [ 32.304975] [<ffffffffa000c6ce>] blkif_interrupt+0x76e/0x820 [xen_blkfront] [ 32.304986] [<ffffffff811dcc8b>] ? kmem_cache_free+0x1bb/0x1f0 [ 32.304995] [<ffffffff8113079e>] handle_irq_event_percpu+0x3e/0x1e0 [ 32.305003] [<ffffffff8113097d>] handle_irq_event+0x3d/0x60 [ 32.305004] [<ffffffff81133647>] handle_edge_irq+0x77/0x130 [ 32.305004] [<ffffffff813d6217>] __xen_evtchn_do_upcall+0x227/0x350 [ 32.305004] [<ffffffff813d83c3>] xen_evtchn_do_upcall+0x33/0x50 [ 32.305004] [<ffffffff81698c7e>] xen_do_hypervisor_callback+0x1e/0x30 [ 32.305004] <EOI> [ 32.305004] [<ffffffff811af916>] ? copy_pte_range+0x2b6/0x5a0 [ 32.305004] [<ffffffff811af8e6>] ? copy_pte_range+0x286/0x5a0 [ 32.305004] [<ffffffff811b24d2>] ? copy_page_range+0x312/0x490 [ 32.305004] [<ffffffff81083012>] ? dup_mm+0x362/0x680 [ 32.305004] [<ffffffff810847ae>] ? copy_process+0x144e/0x1960 [ 32.305004] [<ffffffff81084e71>] ? do_fork+0x91/0x2c0 [ 32.305004] [<ffffffff81085126>] ? SyS_clone+0x16/0x20 [ 32.305004] [<ffffffff816974d9>] ? stub_clone+0x69/0x90 [ 32.305004] [<ffffffff81697189>] ? system_call_fastpath+0x16/0x1b [ 32.305004] Code: 20 e9 2f ff ff ff 44 89 fa 44 89 ee 48 c7 c7 10 45 8c 81 31 c0 e8 9d 14 00 00 58 5a 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 <0f> 0b 66 66 66 66 90 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 [ 32.305004] RIP [<ffffffff8167eb81>] enter_lazy.part.0+0x4/0x6 [ 32.305004] RSP <ffff88001f803aa8> [ 32.305004] ---[ end trace 49f67f0d85e1ac69 ]--- [ 32.305004] Kernel panic - not syncing: Fatal exception in interrupt Thanks, Sarah

3 6

qemu-kvm-ev-2.9.0-16.el7_4.8.1 now available for testing
by Sandro Bonazzola 18 Oct '17

18 Oct '17

Hi, qemu-kvm-ev-2.9.0-16.el7_4.8.1 <https://cbs.centos.org/koji/buildinfo?buildID=20353> is now available for testing. If no negative feedback will be reported, I'm going to push to release on Monday, October 23rd. Here's the changelog: * Wed Oct 18 2017 Sandro Bonazzola <sbonazzo(a)redhat.com> - ev-2.9.0-16.el7_4.8.1 - Removing RH branding from package name * Fri Sep 15 2017 Danilo Cesar Lemes de Paula <ddepaula(a)redhat.com> - rhev-2.9.0-16.el7_4.8 - kvm-ui-move-qemu_input_linux_to_qcode.patch [bz#1482388] - kvm-ui-update-keymaps.patch [bz#1482388] - kvm-ui-add-multimedia-keys.patch [bz#1482388] - kvm-ps2-enable-multimedia-keys.patch [bz#1482388] - kvm-ui-drop-altgr-and-altgr_r-QKeyCodes.patch [bz#1482388] - kvm-ui-drop-ac_search-and-ac_stop.patch [bz#1482388] - Resolves: bz#1482388 (Keys to control audio are not forwarded to the guest [rhel-7.4.z]) * Thu Sep 14 2017 Danilo Cesar Lemes de Paula <ddepaula(a)redhat.com> - rhev-2.9.0-16.el7_4.7 - kvm-vhost-Release-memory-references-on-cleanup.patch [bz#1490742] - Resolves: bz#1490742 (Hot-unplugging a vhost network device leaks references to VFIOPCIDevice's [rhel-7.4.z]) * Tue Sep 05 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.6 - kvm-ps2-fix-sending-of-PAUSE-BREAK-scancodes.patch [bz#1482389] - kvm-ui-correctly-detect-spice-PAUSE-scancode-sequence.patch [bz#1482389] - kvm-vhost-ensure-vhost_ops-are-set-before-calling-iotlb-.patch [bz#1480446] - kvm-vhost-user-unregister-slave-req-handler-at-cleanup-t.patch [bz#1480446] - Resolves: bz#1480446 (vhost-user/iommu: crash when backend disconnects [rhel-7.4.z]) - Resolves: bz#1482389 (Unable to send PAUSE/BREAK to guests in VNC or SPICE [rhel-7.4.z]) -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> <http://www.teraplan.it/redhat-osd-2017/>

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt