Re: Windows 2003: ping -n doesn't wait

[Dor Laor <dlaor@redhat.com>]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>