My hardware and the way I run my VM are both now very different from
back then, and I haven't had the issue described here for years. So
either it was fixed or I'm no longer an accurate test subject.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscr
I haven't remembered to reset those interrupts in a year, but I also
haven't remembered to update my drivers in about as long, so I could be
still on the right setting. I've also been on AMD for that year, and I
don't remember whether this bug applies to modern AMD cards.
--
You received this bug
I just reported the bug in the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=197951
If you reported or commented on the bug here, please go comment on that
report confirming as well. A lot of open-source bugzilla projects tend
to rarely pay attention to bug reports that only one person has
c
I have yet to try disabling swap, but in the 5 days since I downgraded
the kernel to 4.12.12 from 4.12.13, I have not had a single BSOD. I
think 4.12.13 is the culprit.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
Specifically 4.12.12, because it seems that was the last version I was
running before this issue started (I was on 4.12.13 when it started). I,
too, can't find any other package upgrade that could have possibly been
the culprit. The timing of my upgrades of any qemu or libvirt packages
rule them ou
I'm experiencing this BSOD issue as well. I'm also on Arch x64, and the
same versions of everything (though not minimal qemu--just the normal
package in the main repos). I also passthru a GPU and a USB card, but
not an SSD. It will happen randomly, anytime, at least once a day, and
it seems like de
Oh, that is interesting. Using lscpi -v on my computer reveals that
Linux tends to default to enabling MSI on my PCIe devices that support
it (since the common opinion is that it's better for PCIe), including
all my graphics cards, so the fact that vfio-pci and Windows 10 both
default to disabling
(Forgot to clarify: yes, vfio-pci devices disable MSI by default for me
just like for Clif Houck, but all other PCIe devices have it enabled.)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580459
Ti
I enabled MSI interrupts, and now for 2 nights in a row I gamed 2 hours
straight and shut down the Windows VM without a freeze. Never in my 7
months of living with this bug have I gotten no freeze twice in a row. I
think the MSI interrupts have fixed it for me, and no, I did not remove
my HDMI soun
What are MSI interrupts and how did you configure your card to use them?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580459
Title:
Windows (10?) guest freezes entire host on shutdown if using PC
I managed to fix that issue and properly load the VM with the rom file
(what had gone wrong was it inexplicably acted like it had no hard
drives, until I restored the libvirt XML file from a backup). I got a
good test out of it: played video games in Windows for 2 hours, with the
rom file loaded. I
I got impatient and got the rom file from EVGA and loaded it in, but for
me and my GTX 960, I get no graphical output when it's loaded. I don't
know anything beyond that. I don't get any error messages in dmesg or
anything--just no video output whatsoever. It was also strangely booting
into the Tia
Can someone else please confirm that? I can't test it because nouveau
doesn't support the GTX 960 yet. If it turns out solid, then I could
just ask EVGA support for the rom file.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:/
I've been not using USB host passthrough this whole time, as my PCI USB3
card covers that need pretty well. Speaking of those cards, for those of
you who also use one, does it work perfectly? If so, I'd like to know
its model so I can go buy it, because while my card works, about 50% of
the time I
If your Windows VM does and always has a sound card being passed in
(like the .1 address of your video card), then we can't know for sure
that you don't have that other bug. In that other bug, you can fix the
crash by not passing in any sound cards, real or virtual, to the VM.
It's definitely not t
Hm. Sound was the issue in that other bug. Have you already confirmed
that you don't have that other, similar bug? If you undo all the other
fixes you've done, including enabling SND again, does the VM still crash
if you have NO sound device assigned to it at all, whether it be a pass-
thru device
I know it didn't with the GTX 660. It worked perfectly fine. But, I went
fully into Steam streaming everything before I got the 960, so the 960
could have that issue for all I know.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
http
Well, that's a bunch more stuff ruled out. My host is a BIOS with MBR
partitioning, using ext4, and the images are all raw. For each guest,
there's an image of the OS (so the C: drive on Windows and the /
partition on Linux) on my SSD, and Windows also has a bigger image on my
HDD (drive D:). I don
Remember, I think we've done enough testing to know that it isn't
specifically the VM shutting down that causes this, but the binding or
unbinding of PCI devices in sysfs, which is something a VM will do on
shutdown if you're passing hardware into it. It *is* caused by the VM
running for more than
Well, now we finally know that it isn't the i7-5820K's or X99 chipset's
or LGA 2011 socket's faults.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580459
Title:
Windows (10?) guest freezes entire
OK, I figured out how to delete it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580459
Title:
Windows (10?) guest freezes entire host on shutdown if using PCI
passthrough
Status in QEMU:
Ne
Whoops, I clicked the wrong button and added the wrong thing for Arch
Linux, and I don't know how to delete it. (new to launchpad here)
** Also affects: archlinux-lp
Importance: Undecided
Status: New
** Also affects: archlinux
Importance: Undecided
Status: New
** Changed in:
I doubt you have a different issue. My VM has randomly hanged my
computer without a shut down a few times during the life of this bug,
and there are two very possible ways it could happen: the VM suddenly
crashed, making a situation similar to it shutting down, or something in
your host caused some
Also, yeah, the Linux one is called SteamOS, but it is actually just an
almost identical install of Arch. SteamOS wasn't playing nice with most
of my hardware when I tried to install it.
** Attachment added: "SteamOS.xml"
https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4667053/+files/
I should also post my "scripts" (libvirt XML files in my case):
But, since the Windows VM and Linux VM are completely identical beyond
the OS that's installed, I don't think our VM configurations have
anything to do with this bug. I mean, they aren't completely identical
right now because I remove
Oh, I should post my hardware:
i7-5820K (also) (4/6 cores (8/12 threads) being passed to VMs)
12GB RAM (also) (8GB being passed to VMs)
MSI X99 SLI Plus (though I don't use SLI)
NVidia GTX 960 2GB pass-thru (also had this problem on a GTX 660 before that
died)
GT 740 host card, using nouveau when
Public bug reported:
Problem: after leaving a Windows VM that uses PCI passthrough (as we do
for gaming graphics cards, sound cards, and in my case, a USB card)
running for some amount of time between 1 and 2 hours (it's not
consistent with exactly how long), and for any amount of time longer
than
On Sep 4, 2007, at 4:38 PM, Paul Brook wrote:
On Tuesday 04 September 2007, Hollis Blanchard wrote:
On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote:
This could be very valuable when thinking about running qemu *on*
embedded systems with constrained memory and processing power,
which is
28 matches
Mail list logo
