[Qemu-devel] qemu-system-sparc64 hang (possibly virtio related?) with 2.1

[Mark Cave-Ayland]

Hi all,

I've had a couple of reports of virtio hangs with qemu-system-sparc64 
from QEMU 2.1 and I've recently been given access to one of the systems 
in question for testing since I've been unable to reproduce it locally 
myself.

After some initial investigations, it seems that the following factors 
are involved:


1) qemu-system-sparc64 is started with a virtio-enabled kernel and a 
virtio block device with the following command line:

qemu-system-sparc64 -M sun4u -nographic -net nic,model=virtio -net user 
-drive file=qemu-sparc64.img,if=virtio,index=0 -kernel 
qemu-sparc64-archive-kernel

I've been unable to reproduce the hang with the standard cmd646 IDE 
interface.

2) The host system is generally under high load at the time (the 
particular system I'm looking at seems to run periodic build scripts 
which make the system fairly unresponsive at times)

The test case involves extracting a large .tar.gz file on the virtio 
device repeatedly until the point at which it hangs.

3) The hang appears to be random in that whilst extracting the large 
.tar.gz file, the console output stops at different positions each time.


I can immediately think of 2 possibilities: the first is that possibly 
something is happening to the -nographic console since extracting a 
large .tar.gz file generates a lot of output; however the second report 
I've had of this was just a freeze during the Debian installer which 
makes me think this is less likely.

The second possibly is something related to virtio, which seems more 
likely since if I restart qemu-system-sparc64 with the same image after 
a hang then I see reports of bad/missing inodes on the console which 
implies that something has gone wrong writing to the disk.

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?


Many thanks,

Mark.