Sven Rudolph wrote:
Hello,
first the facts required by bug reporting guidelines:
- two Quad-Core AMD Opteron(tm) Processors 2352
- kvm-83 (both kernel and userland)
- Host kernel: 2.6.28.1, x86_64
- guest:
- 4 CPUs assigned to this guest (-smp 4)
- Microsoft Windows 2003 Server, Standard Edition, Service Pack 2
- qemu command line:
qemu-system-x86_64 -m 4096 -boot c -hda hda.dat -smp 4 \
-net nic,macaddr=00:50:56:24:0b:37,model=virtio \
-net tap,ifname=vm03,script=no,downscript=no
The problem: When running "ping -n 3 localhost" on the guest it should
wait one second between each ping request and the time needed should
be non-negative and below 10 ms. Instead, ping does not actually wait
between sending the packets, and the time for the requests ist often
displayed to be too large or negative. Simple examples:
[WinNT] ping -n 3 localhost
Ping wird ausgefhrt fr localhost [127.0.0.1] mit 32 Bytes Daten:
Antwort von 127.0.0.1: Bytes=32 Zeit=-465ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit=-613ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit=-465ms TTL=128
Ping-Statistik fr 127.0.0.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = -613ms, Maximum = -465ms, Mittelwert = 1431655251ms
[WinNT] ping -n 3 localhost
Ping wird ausgefhrt fr localhost [127.0.0.1] mit 32 Bytes Daten:
Antwort von 127.0.0.1: Bytes=32 Zeit=14699ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit=14699ms TTL=128
Antwort von 127.0.0.1: Bytes=32 Zeit=14699ms TTL=128
Ping-Statistik fr 127.0.0.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 14699ms, Maximum = 14699ms, Mittelwert = 14699ms
This makes the problem disappear:
- -smp 1
And these do not make the problem disappear:
- -no-kvm-irqchip
- -no-kvm-pit
Testing with -no-kvm makes no sense because -no-kvm only works with
one CPU (and using "-smp 4 -no-kvm" causes an immediate segfault).
In addition I tried the -clock options. hpet and rtc didn't run
("could not initialize alarm timer"); and dynticks and unix didn't
make the problem disappear.
Ideas, hints, or requests for more info?
It's an unsync tsc issue. I have it reproduced also over latest head.
Marcelo, can you comment on it?
Sven
--
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
--
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
