Re: [Xen-devel] qemu-upstream triggering OOM killer

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 16 Feb 2017, Jan Beulich wrote:
> >>> On 16.02.17 at 16:23, <JBeulich@xxxxxxxx> wrote:
> >>>> On 14.02.17 at 15:56, <anthony.perard@xxxxxxxxxx> 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.

I would bisect it. It's probably due to a change in the cirrus vga code
or common vga code. It might be worth testing with stdvga=1 to narrow it
down.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel