[Kernel-packages] [Bug 1632045] Comment bridged from LTC Bugzilla
--- Comment From s...@us.ibm.com 2016-11-21 09:41 EDT--- Sorry for the delay. This code patch works as designed. There are some related issues that we will address elsewhere, if need be. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1632045 Title: KVM: PPC: Book3S HV: Migrate pinned pages out of CMA Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Released Bug description: ---Problem Description--- https://github.com/open-power/supermicro-openpower/issues/59 SW/HW Configuration PNOR image version: 5/3/2016 BMC image version: 0.25 CPLD Version: B2.81.01 Host OS version: Ubuntu 16.04 LTS UbuntuKVM Guest OS version: Ubuntu 14.04.4 LTS HTX version: 394 Processor: 00UL865 * 2 Memory: SK hynix 16GB 2Rx4 PC4-2133P * 16 Summary of Issue Two UbuntuKVM guests are each configured with 8 processors, 64 GB of memory, 1 disk of 128 GB, 1 network interface, and 1 GPU (pass- through'd from the Host OS's K80). The two guests are each put into a Create/Destroy loop, with HTX running on each of the guests (NOT HOST) in between its creation and destruction. The mdt.bu profile is used, and the processors, memory, and the GPU are put under load. The HTX session lasts 9 minutes. While this is running, the amount of available memory (free memory) in the Host OS will slowly decrease, and this can continue until the point wherein there's no more free memory for the Host OS to do anything, including creating the two VM guests. It seems to be that after every cycle, a small portion of the memory that was allocated to the VM guest does not get released back to the Host OS, and eventually, this can and will add up to take up all the available memory in the Host OS. At some point, the VM guest(s) might get disconnected and will display the following error: error: Disconnected from qemu:///system due to I/O error error: One or more references were leaked after disconnect from the hypervisor Then, when the Host OS tries to start the VM guest again, the following error shows up: error: Failed to create domain from guest2_trusty.xml error: internal error: early end of file from monitor, possible problem: Unexpected error in spapr_alloc_htab() at /build/qemu-c3ZrbA/qemu-2.5+dfsg/hw/ppc/spapr.c:1030: 2016-05-23T16:18:16.871549Z qemu-system-ppc64: Failed to allocate HTAB of requested size, try with smaller maxmem The Host OS syslog, as seen HERE, also contains quite some errors. To just list a few: May 13 20:27:44 191-136 kernel: [36827.151228] alloc_contig_range: [3fb800, 3fd8f8) PFNs busy May 13 20:27:44 191-136 kernel: [36827.151291] alloc_contig_range: [3fb800, 3fd8fc) PFNs busy May 13 20:27:44 191-136 libvirtd[19263]: *** Error in `/usr/sbin/libvirtd': realloc(): invalid next size: 0x01000a780400 *** May 13 20:27:44 191-136 libvirtd[19263]: === Backtrace: = May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x8720c)[0x3fffaf6a720c] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x96f70)[0x3fffaf6b6f70] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(realloc+0x16c)[0x3fffaf6b87fc] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virReallocN+0x68)[0x3fffaf90ccc8] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so(+0x8ef6c)[0x3fff9346ef6c] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so(+0xa826c)[0x3fff9348826c] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virEventPollRunOnce+0x8b4)[0x3fffaf9332b4] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virEventRunDefaultImpl+0x54)[0x3fffaf931334] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virNetDaemonRun+0x1f0)[0x3fffafad2f70] May 13 20:27:44 191-136 libvirtd[19263]: /usr/sbin/libvirtd(+0x15d74)[0x52e45d74] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x2319c)[0x3fffaf64319c] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xb8)[0x3fffaf6433b8] May 13 20:27:44 191-136 libvirtd[19263]: === Memory map: May 13 20:27:44 191-136 libvirtd[19263]: 52e3-52eb r-xp 08:02 65540510 /usr/sbin/libvirtd May 13 20:27:44 191-136 libvirtd[19263]: 52ec-52ed r--p 0008 08:02 65540510 /usr/sbin/libvirtd May 13
[Kernel-packages] [Bug 1632045] Comment bridged from LTC Bugzilla
--- Comment From sarah.han...@us.ibm.com 2016-10-14 12:38 EDT--- When can we expect the patch? This defect is still blocking many of our tests. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1632045 Title: KVM: PPC: Book3S HV: Migrate pinned pages out of CMA Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: In Progress Bug description: ---Problem Description--- https://github.com/open-power/supermicro-openpower/issues/59 SW/HW Configuration PNOR image version: 5/3/2016 BMC image version: 0.25 CPLD Version: B2.81.01 Host OS version: Ubuntu 16.04 LTS UbuntuKVM Guest OS version: Ubuntu 14.04.4 LTS HTX version: 394 Processor: 00UL865 * 2 Memory: SK hynix 16GB 2Rx4 PC4-2133P * 16 Summary of Issue Two UbuntuKVM guests are each configured with 8 processors, 64 GB of memory, 1 disk of 128 GB, 1 network interface, and 1 GPU (pass- through'd from the Host OS's K80). The two guests are each put into a Create/Destroy loop, with HTX running on each of the guests (NOT HOST) in between its creation and destruction. The mdt.bu profile is used, and the processors, memory, and the GPU are put under load. The HTX session lasts 9 minutes. While this is running, the amount of available memory (free memory) in the Host OS will slowly decrease, and this can continue until the point wherein there's no more free memory for the Host OS to do anything, including creating the two VM guests. It seems to be that after every cycle, a small portion of the memory that was allocated to the VM guest does not get released back to the Host OS, and eventually, this can and will add up to take up all the available memory in the Host OS. At some point, the VM guest(s) might get disconnected and will display the following error: error: Disconnected from qemu:///system due to I/O error error: One or more references were leaked after disconnect from the hypervisor Then, when the Host OS tries to start the VM guest again, the following error shows up: error: Failed to create domain from guest2_trusty.xml error: internal error: early end of file from monitor, possible problem: Unexpected error in spapr_alloc_htab() at /build/qemu-c3ZrbA/qemu-2.5+dfsg/hw/ppc/spapr.c:1030: 2016-05-23T16:18:16.871549Z qemu-system-ppc64: Failed to allocate HTAB of requested size, try with smaller maxmem The Host OS syslog, as seen HERE, also contains quite some errors. To just list a few: May 13 20:27:44 191-136 kernel: [36827.151228] alloc_contig_range: [3fb800, 3fd8f8) PFNs busy May 13 20:27:44 191-136 kernel: [36827.151291] alloc_contig_range: [3fb800, 3fd8fc) PFNs busy May 13 20:27:44 191-136 libvirtd[19263]: *** Error in `/usr/sbin/libvirtd': realloc(): invalid next size: 0x01000a780400 *** May 13 20:27:44 191-136 libvirtd[19263]: === Backtrace: = May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x8720c)[0x3fffaf6a720c] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x96f70)[0x3fffaf6b6f70] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(realloc+0x16c)[0x3fffaf6b87fc] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virReallocN+0x68)[0x3fffaf90ccc8] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so(+0x8ef6c)[0x3fff9346ef6c] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so(+0xa826c)[0x3fff9348826c] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virEventPollRunOnce+0x8b4)[0x3fffaf9332b4] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virEventRunDefaultImpl+0x54)[0x3fffaf931334] May 13 20:27:44 191-136 libvirtd[19263]: /usr/lib/powerpc64le-linux-gnu/libvirt.so.0(virNetDaemonRun+0x1f0)[0x3fffafad2f70] May 13 20:27:44 191-136 libvirtd[19263]: /usr/sbin/libvirtd(+0x15d74)[0x52e45d74] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(+0x2319c)[0x3fffaf64319c] May 13 20:27:44 191-136 libvirtd[19263]: /lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xb8)[0x3fffaf6433b8] May 13 20:27:44 191-136 libvirtd[19263]: === Memory map: May 13 20:27:44 191-136 libvirtd[19263]: 52e3-52eb r-xp 08:02 65540510 /usr/sbin/libvirtd May 13 20:27:44 191-136 libvirtd[19263]: 52ec-52ed r--p 0008 08:02 65540510 /usr/sbin/libvirtd May 13 20:27:44 191-136 libvirtd[19263]: 52ed-52ee rw-p 0009 08:02 65540510 /usr/sbin/libvirtd