[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1728256] Re: (Regression) Memory corruption in Windows

From: Wüstengecko
Subject: [Qemu-devel] [Bug 1728256] Re: (Regression) Memory corruption in Windows 10 guest / amd64
Date: Tue, 14 Nov 2017 20:47:30 -0000

It happened again, both with the e1000 and the rtl8139 NICs under qemu
2.11.0.rc0-7-g4ffa88c99c. Kernel is the official Arch one, right now on

At this point I have no idea anymore what could be causing this, and am
unable to test without having to remove basic functionality from the VM
(e.g. the graphics card) or downgrading the host kernel (which I really
want to avoid because I'm using btrfs).

That said, during the last several days I did not experience these weird
hangup issues that I described previously, however I did see very high
CPU load in the guest that was caused by the network (listed in task
manager as System Interrupts, and going as high as one full CPU core
during large network operations).

What is most interesting though is that it survived while I tried my
best to get it to crash (stress-testing CPU and network, mostly), and
then hit me with a Bluescreen in a most unexpected time almost a week
later. Since then however it started crashing anywhere between a few
hours and about two days of consecutive uptime again, just like before.

@larsk, could you elaborate on your setup? Like, in which ways is it different 
(other than you using Ubuntu and thus different versions of the involved 
Which hardware do you pass through, if any?

** Summary changed:

- (Regression) Memory corruption in Windows 10 guest / amd64
+ Memory corruption in Windows 10 guest / amd64

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  Memory corruption in Windows 10 guest / amd64

Status in QEMU:

Bug description:
  I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 
host. The VM has a physical GPU passed through, as well as the physical USB 
controllers, as well as a dedicated SSD attached via SATA; you can find the 
complete libvirt xml here: https://pastebin.com/U1ZAXBNg
  I built qemu from source using the qemu-minimal-git AUR package; you can find 
the build script here: 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you 
aren't familiar with Arch, this is essentially a bash script where build() and 
package() are run to build the files, and then install them into the $pkgdir to 
later tar them up.)

  Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen
  about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads
  f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0,
  which is running stable for over 50 hours right now.

  During my tests I found that locking the memory pages alleviates the
  problem somewhat, but never completely avoids it. However, with the
  crashes occuring randomly, that could as well be false conclusions; I
  had crashes within minutes after boot with that too.

  I will now start `git bisect`ing; if you have any other suggestions on
  what I could try or possible patches feel free to leave them with me.

To manage notifications about this bug go to:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]