framebuf STOP BSOD and performance regression ubuntu10.21 to ubuntu10.22
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Marc Deslauriers | ||
Xenial |
Fix Released
|
High
|
Marc Deslauriers |
Bug Description
Hi,
Corporate environment, Windows XenU platforms, using QEMU HVM (qemu-system-x86) on multiple Ubuntu Xen0 platforms. Established stable production environment (for > 1-5 years), Ubuntu and Windows nodes getting latest patches etc. Dell R6XX series server hardware.
After updates from mainline: 1:2.5+dfsg-
Windows Server 2012, does come up after 4+ minutes booting.
Windows Server 2008R8, Windows 7 Pro, Windows 10 Pro VMs fail to boot with blue screen "framebuf" STOP. (PNG available).
Boot to safe mode (very slow ~ 4mins to login screen) and remove video drivers, reboot succeeds, windows drivers auto updated, reboot fails.
Testing completed on Windows Server 2008R8 images including migration of VM Disk devices to other Dell rack servers:
o Xenial Xen0 server - Same issues
o Trusty Xen0 server - Same issues
o Precise Xen0 server - Fast boot / no issues
On Xenial systems, downgrading qemu-system-x86 to version 1:2.5+dfsg-
Tested PPA versions of qemu-system-x86 with local dpkg installs, version ubuntu10.21 works fine, ubuntu10.22 fails. Proposed ubuntu10.23 also fails.
QEMU Command line used (unchanged between good and back observations):
/usr/bin/
-xen-domid 9
-chardev socket,
-no-shutdown
-mon chardev=
-chardev socket,
-mon chardev=
-nodefaults
-name HOSTNAME
-vnc <IP ADDRESS>
-display none
-serial pty
-device cirrus-
-boot order=c
-usb
-usbdevice tablet
-smp 2,maxcpus=2
-device rtl8139,
-netdev type=tap,
-machine xenfv
-m 6992
-drive file=/dev/
Xen CFG:
name = '<HOSTNAME>'
builder = 'hvm'
memory = 7000
vcpus=2
shadow_memory = 8
acpi=1
vif = ['type=ioemu, bridge=xenbr0']
disk = [ 'phy:/dev/
boot='c'
usbdevice='tablet'
vnc=1
vncdisplay=
vnclisten='<IP ADDRESS>'
vncconsole=1
serial='pty'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
Xen GPL gplpv_Vista2008
CVE References
Changed in qemu (Ubuntu Trusty): | |
status: | New → In Progress |
Changed in qemu (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in qemu (Ubuntu Trusty): | |
assignee: | nobody → Marc Deslauriers (mdeslaur) |
Changed in qemu (Ubuntu Xenial): | |
assignee: | nobody → Marc Deslauriers (mdeslaur) |
Changed in qemu (Ubuntu): | |
status: | New → Invalid |
Changed in qemu (Ubuntu Trusty): | |
importance: | Undecided → High |
Changed in qemu (Ubuntu Xenial): | |
importance: | Undecided → High |
summary: |
- Regression in vga handling ubuntu10.21 to ubuntu10.22 + framebuf STOP BSOD and performance regression ubuntu10.21 to ubuntu10.22 |
Hi Carl,
thank you for your detailed report!
This is the second qemu/xen bug for regressions in these security updates in one day - with none (=0) of them over the last two years - unlikely to be a coincidence.
@Marc - I don't see an obvious change, but you have way more context on these changes since you have backported them. Do you have any info of a potential regression in them?
Maybe the CVE-2018-5683 change?
@Carl - your detailed steps are already great. installed windows as well?
Could you give it a try if the same applies to a unmodified (gplpv) and non-prepared/
Maybe by using an ISO of [1] in your already prepared setup - and if it fails as well sharing the commands you did for that as well? That would make it even better to reproduce.
@Carl - we have another report on even Lubuntu iso's stalling. If you could (since all other parts of your setup are already ready) try the same with a boot from [2] - that is reported to hang with the new version.
If the steps above could be confirmed I'd expect that helps Marc a lot to look into the individual changes in this regard.
Probably related to bug: 1752375
[1]: https:/ /www.microsoft. com/software- download/ windows10 cdimage. ubuntu. com/lubuntu/ releases/ 17.10.1/ release/ lubuntu- 17.10.1- desktop- amd64.iso
[2]: http://
P.S. If this doesn't reproduce for us, but Mark would provide ppa builds with individual fixes - would you be willing and able to check them?