Bug ID 958354
Summary Failed to reserve VRAM on QEMU/KVM with -vga option
Classification openSUSE
Product openSUSE Tumbleweed
Version 2015*
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component KVM
Assignee kvm-bugs@forge.provo.novell.com
Reporter tiwai@suse.com
QA Contact qa-bugs@suse.de
Found By ---
Blocker ---

TW 20151201, kernel 4.3.

After installing a system on QEMU/KVM with -vga cirrus, restart the image with
-vga std.  Then it fails to get the VRAM area, thus it fails switching to KMS. 
This leads to the total lost of FB and VT console.  Although X can start
afterward, but it's in UMS, i.e. old VESA driver.

The same problem happens in vice versa, i.e. installing with -vga std, then
reboot with -vga cirrus.  The point is that another DRM driver is included in
initrd and plymouth is enabled.

My wild guess (and my vague memory for a similar bug) is that plymouth takes
the control on the VGA, and this blocks the switching.  Actually, when I boot
with plymouth.enable=0 or attaching a serial console, the problem is gone.

Or, when I reload the KMS module after login on UMS, now it works: the VT is
created and FB is attached there, too.  It's because plymouth already quits, so
VRAM got freed.

I'm not sure what is the best way to fix this yet.  There is no reason to
restrict the access in the kernel side (although there is lots of rooms to
improve there, too).   Maybe we can have a workaround in either plymouth or
dracut.


You are receiving this mail because: