Bug 1732113 - Recent Rawhide kernels (rc0.git7 and rc1) have problems with qemu 'std' / 'VGA' driver
Summary: Recent Rawhide kernels (rc0.git7 and rc1) have problems with qemu 'std' / 'VG...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 17:52 UTC by Adam Williamson
Modified: 2026-07-25 01:15 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-07-25 01:15:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2019-07-22 17:52:08 UTC
Since kernel-5.3.0-0.rc0.git7.1.fc31 landed in Rawhide, in the Fedora-Rawhide-20190720.n.1 compose, almost all openQA tests are failing. Investigating this manually, it seems to be due to issues with the qemu graphics driver which qemu calls 'std' and virt-manager calls 'VGA'.

With rc0.git7, there seem to be issues with VTs. Booting to runlevel 3 gets stuck at a black screen. Similarly, trying to switch to a VT from a running graphical desktop does not work; openQA shows a black screen when it tries to do this, when I try it in a local VM, I see some of the GNOME desktop elements disappear but then the screen freezes (cursor not moveable). Sometimes I can successfully switch back to the running GNOME session with ctrl-alt-f2, sometimes I can't.

With rc1.git0.1, my VM won't even boot to GNOME any more if the graphics are set to 'VGA'. It just gets stuck at a boot splash screen.

If I change the VM to use qxl or virtio graphics, everything is fine, with both kernels.

This is a problem because openQA runs into other issues if I set it to use qxl or virtio graphics. The last one we had with qxl was https://bugzilla.redhat.com/show_bug.cgi?id=1638578 , the last one we had with virtio was https://bugzilla.redhat.com/show_bug.cgi?id=1638578 . I guess I'll have to try out qxl again and see what happens.

Comment 1 Adam Williamson 2019-07-22 17:53:03 UTC
huh, actually, rc1 doesn't seem to boot even with virtio graphics. But that's probably a different problem.

Comment 2 Cole Robinson 2019-07-23 20:39:14 UTC
I see Gerd had a patch to vga/bochs recently, but it should be in 5.3-rc1 which you also report issues with

commit dd2b5959785c75c23ab2295a4095700e47dabff3
Author: Gerd Hoffmann <kraxel>
Date:   Thu Jun 27 10:12:06 2019 +0200

    drm/bochs: fix framebuffer setup.


Gerd, any thoughts?

Comment 3 Adam Williamson 2019-07-23 20:44:42 UTC
The failure I saw when testing RC1 was probably this SCSI thing:

https://marc.info/?l=linux-scsi&m=156378725427719&w=2

so unrelated. I'll try and find or build a kernel with both things fixed, or see if I can hack up a VM to avoid the SCSI problem with RC1 so I can check if this video problem is gone.

Comment 4 Adam Williamson 2019-07-23 20:55:08 UTC
OK, nope, still seems broken with 5.3.0-0.rc1.git0.1.fc31.x86_64 (I got it booting in my test VM).

Comment 5 Adam Williamson 2019-07-23 22:13:57 UTC
5.3.0-0.rc1.git1.1.fc31.x86_64 also still broken.

Comment 7 Adam Williamson 2019-08-01 16:40:09 UTC
Thanks for that. virtio has been working quite well, so I might stick with it long term, but if someone gives me a heads-up when those fixes are in a Fedora kernel build I can kick staging back to std to test them.

Comment 8 Gerd Hoffmann 2019-08-02 06:37:08 UTC
Fixes are in drm-misc-fixes branch now.
Might be too late for -rc3, but -rc4 should be fixed.

Comment 9 Charles Haithcock 2026-07-24 14:54:17 UTC
This report has not received an update in over 90 days. If this issue is still relevant to you, please do not hesitate to update this report with any relevant details on recent investigative steps or changes and we will absolutely work to understand how to best move forward. Otherwise, this bug report will need to be closed in 30 days. No worries, however; should you need still assistance after the report is closed, please do not hesitate to create a new bug report referencing this report and with any new details on the matter. 

NOTE: This is an automated mass update.

Comment 10 Adam Williamson 2026-07-25 01:15:34 UTC
erf, well, we've just stuck with virtio since then, never did get around to re-testing std. let's assume it's fixed.


Note You need to log in before you can comment on or make changes to this bug.