On Wed, 20 Jan 2016 03:28:04 -0500 (EST) Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Can you reproduce it on the host without QEMU in the middle? I did not try to stress-test this on purpose yet, but this is an actively used system which is snapshotting its /home, VMs and root subvolumes every hour, so far no lock-ups of any other application than KVM, and with KVM it's trivially easy to hit, in fact first two lockups occured in the first two hours of using the kernel 4.4.0 at the hourly snapshots... > Also, can you find the value of the "FUA" file in sysfs (e.g. with > "cat /sys/block/sda/device/scsi_disk/*/FUA")? It is 0 both in IDE and SCSI modes. Since you mentioned queue depth, I tried setting this on SCSI: echo 1 > /sys/block/sda/device/queue_depth (was 128 by default). Does not solve the issue and doesn't seem to make it any harder to hit. Couple more details about the locked-up state: - 0.0% "wa" state in 'top', so there's doesn't seem to be any disk activity - I can disconnect and then successfully reconnect to the VNC port of the locked-up QEMU/KVM process (!), so it looks like it's not entirely dead, but just the virtualization part(?) -- With respect, Roman
Attachment:
signature.asc
Description: PGP signature
