[Top][All Lists]

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

[Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA

From: John Snow
Subject: [Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA
Date: Fri, 25 May 2018 01:08:39 -0000

I tried bisecting as well, and I wound up at:

1a423896 -- five out of five boot attempts succeeded.
d759c951 -- five out of five boot attempts failed.

d759c951f3287fad04210a52f2dc93f94cf58c7f is the first bad commit
commit d759c951f3287fad04210a52f2dc93f94cf58c7f
Author: Alex Bennée <address@hidden>
Date:   Tue Feb 27 12:52:48 2018 +0300

    replay: push replay_mutex_lock up the call tree

My methodology was to boot QEMU like this:

./x86_64-softmmu/qemu-system-x86_64 -m 4096 -cpu host -M q35 -enable-kvm
-smp 4 -drive id=sda,if=none,file=/home/bos/jhuston/windows_10.qcow
-device ide-hd,drive=sda -qmp tcp::4444,server,nowait

and run it three times with -snapshot and see if it hung during boot; if
it did, I marked the commit bad. If it did not, I booted and attempted
to log in and run CrystalDiskMark. If it froze before I even launched
CDM, I marked it bad.

Interestingly enough, on a subsequent (presumably bad) commit (6dc0f529)
which hangs fairly reliably on bootup (66%) I can occasionally get into
Windows 10 and run CDM -- and that unfortunately does not seem to
trigger the error again, so CDM doesn't look like a reliable way to
trigger the hangs.

Anyway, d759c951 definitely appears to change the odds of AHCI locking up 
during boot for me, and I suppose it might have something to do with how it is 
changing the BQL acquisition/release in main-loop.c, but I am not sure why/what 

Before this patch, we only lock the iothread and re-lock it if there was
a timeout, and after this patch we *always* lock and unlock the
iothread. This is probably just exposing some latent bug in the AHCI
emulator that has always existed, but now the odds of seeing it are much

I'll have to dig as to what the race is -- I'm not sure just yet.

If those of you who are seeing this bug too could confirm for me that d759c951 
appears to be the guilty party, that probably wouldn't hurt.


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

  Issue with qemu 2.12.0 + SATA

Status in QEMU:

Bug description:
  [EDIT: I first thought that OVMF was the issue, but it turns out to be

  I had a Windows 10 VM running perfectly fine with a SATA drive, since
  I upgraded to qemu 2.12, the guests hangs for a couple of minutes,
  works for a few seconds, and hangs again, etc. By "hang" I mean it
  doesn't freeze, but it looks like it's waiting on IO or something, I
  can move the mouse but everything needing disk access is unresponsive.

  What doesn't work: qemu 2.12 with SATA
  What works: using VirIO-SCSI with qemu 2.12 or downgrading qemu to 2.11.1 and 
keep using SATA.

  Platform is arch linux 4.16.7 on skylake and Haswell, I have attached
  the vm xml file.

To manage notifications about this bug go to:

reply via email to

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