Debian Bug report logs - #922612
qemu-system: black screen when guest goes to powersave, does not come back

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marc Lehmann <debian-reportbug@plan9.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu-system: black screen when guest goes to powersave, does not come back

Date: Mon, 18 Feb 2019 13:43:31 +0100

Package: qemu-system
Version: 1:3.1+dfsg-4
Severity: normal

Dear Maintainer,

after upgrading to qemu 3.1 from stretch, I found that both linux and
windows guests, when using the qxl device, do not come back from deep
power save.

That is, when I run either a standard ubuntu 17.10 or windows 10 (with
qxl-dod driver), then by default they switch off the screen after a while,
which results in black screen in qemu, as expected.

If one moves the mouse or presses a key shortly after this, the screen comes back.

If I let the systems idle for longer (say, half an hour), then they seem
to go into a deeper powersave, and pressing a key or moving the mouse does
NOT restore the screen - it stays black.

When the vm is in this state, I have not found a way to get the display
back, the only way that works is to quit qemu and start it again (meaning
boot the guest again in a new qemu instance, I have not tried to
suspend/resume a vm).

I have verified that mouse inputs and keypresses are registered correctly
by the guest in this state, so I assume it does try to switch on the
virtual monitor.

Since this happens with both linux and windows guests, this looks like a
bug in qemu's display code to me.

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system depends on:
ii  qemu-system-arm    1:2.8+dfsg-6+deb9u5
ii  qemu-system-mips   1:2.8+dfsg-6+deb9u5
ii  qemu-system-misc   1:3.1+dfsg-2+b1
ii  qemu-system-ppc    1:2.8+dfsg-6+deb9u5
ii  qemu-system-sparc  1:2.8+dfsg-6+deb9u5
ii  qemu-system-x86    1:3.1+dfsg-2+b1

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Message #10 received at 922612@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 922612@bugs.debian.org, qemu-devel qemu-devel <qemu-devel@nongnu.org>

Cc: Gerd Hoffmann <kraxel@redhat.com>

Subject: Re: Bug#922612: qemu-system: black screen when guest goes to powersave, does not come back

Date: Wed, 20 Feb 2019 11:33:40 +0300

Forwarding from Debian bugreport http://bugs.debian.org/922612

18.02.2019 15:43, Marc Lehmann wrote:
> Package: qemu-system
> Version: 1:3.1+dfsg-4
> Severity: normal
> 
> Dear Maintainer,
> 
> after upgrading to qemu 3.1 from stretch [from qemu 2.8 -- mjt], I found
> that both linux and windows guests, when using the qxl device, do not
> come back from deep power save.
> 
> That is, when I run either a standard ubuntu 17.10 or windows 10 (with
> qxl-dod driver), then by default they switch off the screen after a while,
> which results in black screen in qemu, as expected.
> 
> If one moves the mouse or presses a key shortly after this, the screen comes back.
> 
> If I let the systems idle for longer (say, half an hour), then they seem
> to go into a deeper powersave, and pressing a key or moving the mouse does
> NOT restore the screen - it stays black.
> 
> When the vm is in this state, I have not found a way to get the display
> back, the only way that works is to quit qemu and start it again (meaning
> boot the guest again in a new qemu instance, I have not tried to
> suspend/resume a vm).
> 
> I have verified that mouse inputs and keypresses are registered correctly
> by the guest in this state, so I assume it does try to switch on the
> virtual monitor.
> 
> Since this happens with both linux and windows guests, this looks like a
> bug in qemu's display code to me.

Thanks,

/mjt

Message #15 received at 922612@bugs.debian.org (full text, mbox, reply):

From: Gerd Hoffmann <kraxel@redhat.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 922612@bugs.debian.org, qemu-devel qemu-devel <qemu-devel@nongnu.org>

Subject: Re: Bug#922612: qemu-system: black screen when guest goes to powersave, does not come back

Date: Thu, 21 Feb 2019 14:47:19 +0100

  Hi,

> > That is, when I run either a standard ubuntu 17.10 or windows 10 (with
> > qxl-dod driver), then by default they switch off the screen after a while,
> > which results in black screen in qemu, as expected.

Just the screen saver I guess.

> > If I let the systems idle for longer (say, half an hour), then they seem
> > to go into a deeper powersave, and pressing a key or moving the mouse does
> > NOT restore the screen - it stays black.

Probably "systemctl suspend".

> > When the vm is in this state, I have not found a way to get the display
> > back, the only way that works is to quit qemu and start it again (meaning
> > boot the guest again in a new qemu instance, I have not tried to
> > suspend/resume a vm).
> > 
> > I have verified that mouse inputs and keypresses are registered correctly
> > by the guest in this state, so I assume it does try to switch on the
> > virtual monitor.

Doesn't reproduce.

Can you log into the machine (serial console, network)?
If so: anything suspicious in the kernel log?

Also: it is possible to disable suspend support (libvirt xml):

  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>

Suspending virtual machines typically adds little benefit and isn't
tested that well, so I'd recommend doing that.

Bugs can be in both host (qemu) and guest (linux kernel driver).   Often
it is quite difficult to debug and to figure who is actually at fault
here.

cheers,
  Gerd

Send a report that this bug log contains spam.