Tomasz Chmielewski wrote:
Felix Leimbach schrieb:
OK, another bug found.
Set your MTU to 100.
On two hosts, do:
HOST1_MTU1500# dd if=/dev/zero | ssh manager@HOST2 dd of=/dev/null
HOST2_MTU100# dd if=/dev/zero | ssh manager@HOST1 dd of=/dev/null
HOST2 with MTU 100 will crash after 10-15 minutes (with packet count
still not overflown).
Intersting. What are the packet counter at crash time (roughly)?
My - currently running - test is:
Guest 1 (Linux):
MTU 150
# cat /dev/zero | nc <guest2ip> 7777
Guest 2 (Windows 2003 Server):
MTU: 1500
# nc -l -p 7777 > NUL
My packet are currently at 63 million without a problem - yet.
I have it running with MTU 1500. And one of the guests (the one which
was crashing with MTU=100) froze.
On a VNC console I can see:
virtio_net virtio0: id 64 is not a head!
BUG: soft lockup - CPU#0 stuck for 61s! [ssh:2265]
And "soft lockup" is being printed periodically. VNC and serial
console do not react to any key press. Guest do not react on ACPI
events (shutdown).
kvm/qemu process is using 100% CPU.
See this screenshot:
http://www1.wpkg.org/lockup.png
Guest that locks up is running Debian Lenny with 2.6.26 kernel.
Guest that does not lock up runs Mandriva 2009.0 with 2.6.27.x kernel.
(data being transferred both side to/from each of these hosts).
Copying the virtio folks... something is wrong.
You can obtain a stack trace of the locked up guest by doing
(qemu) gdbserver 1234
$ gdb /path/to/guest/vmlinux
(gdb) target remote localhost:1234
(gdb) backtrace
I don't know host you obtain the guest vmlinux on debian; on Fedora it
is contained in kernel-debuginfo.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
