Alexander Graf <ag...@suse.de> writes: > On 03.09.14 23:21, Aneesh Kumar K.V wrote: >> "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> writes: >> >>> Stefan Hajnoczi <stefa...@gmail.com> writes: >>> >>>> On Tue, Sep 02, 2014 at 02:12:45PM +0100, Mark Cave-Ayland wrote: >>>>> Fortunately I can reproduce the issue with a debug-enabled build of >>>>> qemu-system-sparc64, and I've posted a backtrace obtained during the hung >>>>> state at http://www.ilande.co.uk/tmp/sparc64-gdb-bt.txt. I can't see >>>>> anything too obvious, other than that the ppoll() could possibly be >>>>> waiting >>>>> for a bad file descriptor? >>>> >>>> The backtrace looks like a normal QEMU run. Nothing obvious there. >>>> >>>> This suggests the QEMU monitor is still operational and the guest is >>>> still executing code. >>>> >>>> Does the I/O time out inside the guest? Normally messages are printed >>>> in dmesg if I/O requests are pending for too long. >>> >>> I am also finding this on ppc64. The system hang even with virtio-9p, so >>> it may not be virtio blk related. git bisect is complicated because few >>> commits in between cause other boot failures with ppc64. >> >> The bad commit is: >> >> git show cc943c36faa192cd4b32af8fe5edb31894017d35 >> commit cc943c36faa192cd4b32af8fe5edb31894017d35 >> Author: Jan Kiszka <jan.kis...@siemens.com> >> Date: Sun Jul 27 09:08:29 2014 +0200 >> >> pci: Use bus master address space for delivering MSI/MSI-X messages > > Does "spapr_pci: map the MSI window in each PHB" from Greg fix this for > you on ppc64? >
Yes that patch fixed the issue for me. Thanks, -aneesh
