Bug 857146

Summary: qemu on i686 hangs during shutdown
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: amit.shah, berrange, cfergeau, dwmw2, itamar, knoel, pbonzini, rjones, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-13 13:26:23 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Richard W.M. Jones 2012-09-13 12:42:22 EDT
Description of problem:

Occasionally 2:qemu-system-x86-1.2.0-3.fc18.i686 is observed
hanging during shutdown.  It seems to particularly happen after
running long tests (eg. make -C tests/c-api check in libguestfs).

Version-Release number of selected component (if applicable):

2:qemu-system-x86-1.2.0-3.fc18.i686

How reproducible:

?

Steps to Reproduce:
1. make -C tests/c-api check
  
Actual results:

qemu-system-i386 hangs during shutdown, consuming 100% CPU.

Expected results:

Should exit instead.

Additional info:

Messages from libguestfs:

libguestfs: closing guestfs handle 0x987dd38 (state 2)
libguestfs: send_to_daemon: 44 bytes: 00 00 00 28 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 00 | ...
guestfsd: main_loop: proc 48 (lvm_remove_all) took 2.15 seconds
guestfsd: main_loop: new request, len 0x28
fsync /dev/sda
fsync /dev/sdb
fsync /dev/sdc
fsync /dev/sdd
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 01 | 00 12 3e 76 | ...

Stack trace to follow.
Comment 1 Richard W.M. Jones 2012-09-13 13:26:23 EDT
Wow, that's strange.  It was working, but it just took
an extraordinarily long time to close the device -- 1 hour.

I'm going to close this bug, but I'll watch out for it
happening again.