Bug 1732113

Summary:	Recent Rawhide kernels (rc0.git7 and rc1) have problems with qemu 'std' / 'VGA' driver
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	airlied, bskeggs, crobinso, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, kraxel, linville, mchehab, mjg59, steved
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	openqa
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-07-25 01:15:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 6 Gerd Hoffmann 2019-08-01 08:57:13 UTC

https://git.kraxel.org/cgit/linux/log/?h=drm-bochs-fixes

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.