>>> On 16.02.17 at 16:23, <jbeul...@suse.com> wrote: >>>> On 14.02.17 at 15:56, <anthony.per...@citrix.com> wrote: >> On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote: >>> Not so far. It appears to happen when grub clears the screen >>> before displaying its graphical menu, so I'd rather suspect an issue >>> with a graphics related change (the one you pointed out isn't). >> >> I tried to reproduce this, by limiting the amount of memory available to >> qemu using cgroups, but about 44MB of memory is enough to boot a guest >> (tried Ubuntu and Debian). > > Okay, not a qemuu regression after all, but a libxc one. It just so > happens that qemut tries to allocate a much larger amount, which > triggers mmap() failure earlier and hence doesn't manage to trigger > the oom killer. Patch (almost) on its way.
Patch sent, allowing that guest to get further (and Windows to properly boot). However, now the guest is stuck right at the point where X wants to switch to its designated video mode, with qemu (for somewhere between half a minute and a minute) consuming one full CPU's bandwidth. Once qemu's CPU consumption went down, no further progress is being made though. Again I'd be thankful for hints on how to debug such a situation. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
