[Qemu-devel] [Bug 1769189] [NEW] Issue with qemu 2.12.0 + UEFI

[Qemu-devel] [Bug 1769189] [NEW] Issue with qemu 2.12.0 + UEFI

[François Guerraz]

Public bug reported:

(first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949
)

I had a Windows 10 VM running perfectly fine with OVMF UEFI, 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 OVMF
What works: using BIOS or downgrading qemu to 2.11.1.

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

** Affects: qemu
     Importance: Undecided
         Status: New

** Attachment added: "libvirt vm description"
   https://bugs.launchpad.net/bugs/1769189/+attachment/5133839/+files/Win10.xml

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + UEFI

Status in QEMU:
  New

Bug description:
  (first reported here:
  https://bugzilla.tianocore.org/show_bug.cgi?id=949 )

  I had a Windows 10 VM running perfectly fine with OVMF UEFI, 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 OVMF
  What works: using BIOS or downgrading qemu to 2.11.1.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Adee]

I'm seeing the same Win10 I/O stall problem with qemu 2.12, but with a vm with BIOS, not UEFI.
The solution for me is only dowgrading for now.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + UEFI

Status in QEMU:
  New

Bug description:
  (first reported here:
  https://bugzilla.tianocore.org/show_bug.cgi?id=949 )

  I had a Windows 10 VM running perfectly fine with OVMF UEFI, 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 OVMF
  What works: using BIOS or downgrading qemu to 2.11.1.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Mathias Bösl]

I have the same issue. When I open the task manager on the virtualized Windows 10 VM I see the HDD time is at 100% but the data transfer rate is actual 0b/s. 
I've tried any combination of the options below and the issue was always reproducible with qemu-2.12.0-1 and never with qemu-2.11.1-2.

Linux kernels:
- 4.14.5-1
- 4.16.7

Windows 10 Verson (for the VM) 
- 1709
- 1803

Boot HDD for VM
- Actual SSD (/dev/sda)
- QCOW2 Image

QEMU 
- qemu-2.11.1-2
- qemu-2.12.0-1


I also use ARCH Linux and have also downgraded to pre 2.12 QEMU

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + UEFI

Status in QEMU:
  New

Bug description:
  (first reported here:
  https://bugzilla.tianocore.org/show_bug.cgi?id=949 )

  I had a Windows 10 VM running perfectly fine with OVMF UEFI, 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 OVMF
  What works: using BIOS or downgrading qemu to 2.11.1.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[François Guerraz]

I have done some further tests and the problem seems to be SATA, not
UEFI, I have updated the bug description to reflect this.

** Summary changed:

- Issue with qemu 2.12.0 + UEFI
+ Issue with qemu 2.12.0 + SATA

** Description changed:

- (first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949
- )
+ [EDIT: I first thought that OVMF was the issue, but it turns out to be
+ SATA]
  
- I had a Windows 10 VM running perfectly fine with OVMF UEFI, since I
+ 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 OVMF
- What works: using BIOS or downgrading qemu to 2.11.1.
+ 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, I have attached the vm xml
- file.
+ Platform is arch linux 4.16.7 on skylake and Haswell, I have attached
+ the vm xml file.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Dr. David Alan Gilbert]

François: Would it be possible for you to try a bisect build to try and
figure out which change in qemu caused the problem?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[blackdevil]

For me it is hangs with SATA, but IDE is fine.

Windows 7 Version (for the VM)
- SP1

Boot HDD for VM
- Actual HDD (/dev/sda)
- QCOW2 Image

QEMU
- qemu-2.12.0-1

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Bruce Rogers]

I've tried bisecting a few times, but since my reproducer wasn't
reliable enough, I didn't identify the issue. (I see a bisect reported
on qemu ML which seems like a bogus result, similar to mine).

In my case, after the "hang", Windows 10 resets the ahci device after 2
minutes and it continues on until another hang happens. Seems fairly
random. I increased the number of vcpu's assigned which seemed to
increase the likelihood of the hang.

I also went so far as to instrument an injection of the ahci interrupt
via the monitor (total kludge, I know), and the guest did get out of the
hung condition right away when I did that.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

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 <alex.bennee@linaro.org>
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 yet.

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
higher.

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.

Thanks!
--js

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Bruce Rogers]

I can confirm that for me commit d759c951 does cause / expose the issue.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

There might be multiple issues present and I'm having difficulty
reliably doing any kind of regression testing here, but I think this
patch helps fix at least one of the issues I was seeing that occurs
specifically during early boot. It may fix other hangs.


** Patch added: "sata.patch"
   https://bugs.launchpad.net/qemu/+bug/1769189/+attachment/5146730/+files/sata.patch

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  New

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

** Changed in: qemu
       Status: New => Confirmed

** Changed in: qemu
     Assignee: (unassigned) => John Snow (jnsnow)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Confirmed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

Oughtta be fixed in current master, will be fixed in 2.12.1 and 3.0.

** Changed in: qemu
       Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Robert Hu]

Hi, Where can I find the fix patch at present?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

5694c7eacce6b263ad7497cc1bb76aad746cfd4e ahci: fix PxCI register race

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5694c7eacce6b263ad7497cc1bb76aad746cfd4e

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Peter Maloney]

Could this affect virtio-scsi? I'm not so sure since it's not perfectly
reliable to reproduce, but v2.12.0 was hanging for me for a few minutes
at a time with virtio-scsi cache=writeback showing 100% disk util%. I
never had issues booting up, and didn't try SATA. v2.11.1 was fine.

My first attempt to bisect didn't turn out right... had some false
positives I guess. The 2nd attempt (telling git the bads from first try)
got to 89e46eb477113550485bc24264d249de9fd1260a as latest good (which is
4 commits *after* the bisect by John Snow) and
7273db9d28d5e1b7a6c202a5054861c1f0bcc446 as bad.

But testing with this patch, it seems to work (or false positive
still... after a bunch of usage). And so I didn't finish the bisect.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[John Snow]

The fix posted exclusively changes the behavior of AHCI devices; however
the locking changes that jostled the AHCI bug loose could in theory
jostle loose some bugs in other devices, too.

I don't think it is possible that the fix for AHCI would have any impact
on virtio-scsi devices.

If you're seeing issues in virtio-scsi, I'd make a new writeup in a new LP.
--js

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Thomas Huth]

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Released

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

  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:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

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

[Andrew Randrianasulu]

For me issue was fixed with «[PATCH 2/3] ahci: fix PxCI register race»

I additionally patched my qemu build with "[PATCH] e1000e: Do not auto-clear ICR 
bits which aren't set in EIAC" - so new network adapter for q35 machine works 
with KDE Neon liveDVD for example ....

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Sun, May 20, 2018 at 08:54:50PM +0300, Andrew Randrianasulu wrote:
> I think I was hit with very same bug.
> 
> I did bisect with 2.11.0 as good point and 2.12.0 as bad point.

Hi Andrew,
Please try John Snow's SATA fixes for QEMU 2.12.0.  If you can't build
QEMU from source you can wait for QEMU 2.12.1 to be released with the
fixes.

The patch series was titled "[PATCH 0/3] ahci: fix completion race
condition".

You can grab it from git here: https://github.com/jnsnow/qemu/commits/ide

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Andrew Randrianasulu]

I think I was hit with very same bug.

I did bisect with 2.11.0 as good point and 2.12.0 as bad point.

configure was 

setarch 
i486 ./configure --prefix=/usr --disable-gtk --enable-virglrenderer --enable-sdl --with-sdlabi=2.0 --audio-drv-list=alsa,oss --host-cc=/opt/gcc49/bin/gcc --enable-opengl --extra-cflags="-I/usr/X11R7/include -O3 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs -Wno-implicit-function-declaration" --disable-werror --target-list="x86_64-softmmu"

and launch command

x86_64-softmmu/qemu-system-x86_64 -cdrom 
~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -enable-kvm -m 1G -M q35



------------
git bisect bad
66eb7825d0bd84a870a054fb208fe765317109fa is the first bad commit
commit 66eb7825d0bd84a870a054fb208fe765317109fa
Author: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
Date:   Tue Feb 27 12:53:05 2018 +0300

    replay: avoid recursive call of checkpoints

    This patch adds a flag which denies recursive call of replay_checkpoint
    function. Checkpoints may be accompanied by the hardware events. When event
    is processed, virtual device may invoke timer modification functions that
    also invoke the checkpoint function. This leads to infinite loop.

    Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
    Message-Id: <20180227095305.1060.56463.stgit@pasha-VirtualBox>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>

:040000 040000 f8d1eb18d3a8fcd0df0329e6b899a515e4b0e16e 
a286be2d590b42b15f9facf033348ee37c460d25 M      replay

-------------

git bisect log
git bisect start
# good: [0a0dc59d27527b78a195c2d838d28b7b49e5a639] Update version for v2.11.0 
release
git bisect good 0a0dc59d27527b78a195c2d838d28b7b49e5a639
# bad: [4743c23509a51bd4ee85cc272287a41917d1be35] Update version for v2.12.0 
release
git bisect bad 4743c23509a51bd4ee85cc272287a41917d1be35
# skip: [db57d7a3c284db2315d92f55962597cc7276579a] wdt_ib700-test: Drop 
dependence on global_qtest
git bisect skip db57d7a3c284db2315d92f55962597cc7276579a
# good: [539022dd6089cdef36589d608ed63cbdaacfd71f] chardev: Clean up previous 
patch indentation
git bisect good 539022dd6089cdef36589d608ed63cbdaacfd71f
# good: [9db0855e8501365334e859370800c240d25322a2] Merge remote-tracking 
branch 'remotes/pmaydell/tags/pull-target-arm-20180301' into staging
git bisect good 9db0855e8501365334e859370800c240d25322a2
# good: [a57946ff2acb9c0d95c9f127914540586b0b8c21] Merge remote-tracking 
branch 'remotes/awilliam/tags/vfio-update-20180313.0' into staging
git bisect good a57946ff2acb9c0d95c9f127914540586b0b8c21
# bad: [211d6260208d079429fd0d447b86ff480d0524ca] Merge remote-tracking 
branch 'remotes/kevin/tags/for-upstream' into staging
git bisect bad 211d6260208d079429fd0d447b86ff480d0524ca
# bad: [09b68dab5a11e8657119bc1d2ab18e98a70530ed] vhdx: Support .bdrv_co_create
git bisect bad 09b68dab5a11e8657119bc1d2ab18e98a70530ed
# bad: [3788c7b6e56fa34ee2a73e41706eb2a2447ba75a] Merge remote-tracking 
branch 'remotes/bonzini/tags/for-upstream' into staging
git bisect bad 3788c7b6e56fa34ee2a73e41706eb2a2447ba75a
# good: [63f01a74aeeb9c4fb39e2b4100beb084f5c10c95] hw/isa/pc87312: Inherit from 
the abstract TYPE_ISA_SUPERIO
git bisect good 63f01a74aeeb9c4fb39e2b4100beb084f5c10c95
# good: [1a96e3c1e7dbb466a8c93743b8f5ae37cc023766] replay: fix processing async 
events
git bisect good 1a96e3c1e7dbb466a8c93743b8f5ae37cc023766
# good: [1a423896fa4fc2ea49c64e7a493d88a8b251950d] replay: don't destroy mutex 
at exit
git bisect good 1a423896fa4fc2ea49c64e7a493d88a8b251950d
# bad: [821c113033075d4f1b50966d92022a1064085422] scripts/replay-dump.py: replay 
log dumper
git bisect bad 821c113033075d4f1b50966d92022a1064085422
# good: [6dc0f5296359ff59c248215a965c8658dea9544b] replay: check return values 
of fwrite
git bisect good 6dc0f5296359ff59c248215a965c8658dea9544b
# bad: [66eb7825d0bd84a870a054fb208fe765317109fa] replay: avoid recursive call 
of checkpoints
git bisect bad 66eb7825d0bd84a870a054fb208fe765317109fa
# first bad commit: [66eb7825d0bd84a870a054fb208fe765317109fa] replay: avoid 
recursive call of checkpoints
------------------------