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? Alex
