[Kernel-packages] [Bug 1632045] Comment bridged from LTC Bugzilla

2016-11-21 Thread bugproxy
--- 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

2016-10-14 Thread bugproxy
--- 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