On 02/21/2016 01:57 PM, Hauke Mehrtens wrote: > Without flushing the vdso data page the vdso call is working on dated > or unsynced data. This resulted in problems where the clock_gettime > vdso call returned a time 6 seconds later after a 3 sounds sleep, > while the syscall reported a time 3 sounds later like expected. This > happened very often and I got these ping results for example: > > root@OpenWrt:/# ping 192.168.1.255 > PING 192.168.1.255 (192.168.1.255): 56 data bytes > 64 bytes from 192.168.1.3: seq=0 ttl=64 time=0.688 ms > 64 bytes from 192.168.1.3: seq=1 ttl=64 time=4294172.045 ms > 64 bytes from 192.168.1.3: seq=2 ttl=64 time=4293968.105 ms > 64 bytes from 192.168.1.3: seq=3 ttl=64 time=4294055.920 ms > 64 bytes from 192.168.1.3: seq=4 ttl=64 time=4294671.913 ms > > The flush is now done like it is done on the arm architecture code. > > This was tested on a Lantiq/Intel VRX288 (MIPS BE 34Kc V5.6 CPU with > two VPEs) > > Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> # v4.4+ I did some more tests and it is better now, but the problem is not completely fixed, see this: root@OpenWrt:/# ping 192.168.1.195 PING 192.168.1.195 (192.168.1.195): 56 data bytes 64 bytes from 192.168.1.195: seq=0 ttl=64 time=0.506 ms 64 bytes from 192.168.1.195: seq=1 ttl=64 time=4294951.724 ms 64 bytes from 192.168.1.195: seq=2 ttl=64 time=0.441 ms 64 bytes from 192.168.1.195: seq=3 ttl=64 time=0.412 ms 64 bytes from 192.168.1.195: seq=4 ttl=64 time=0.440 ms 64 bytes from 192.168.1.195: seq=5 ttl=64 time=0.435 ms 64 bytes from 192.168.1.195: seq=6 ttl=64 time=0.403 ms 64 bytes from 192.168.1.195: seq=7 ttl=64 time=0.406 ms 64 bytes from 192.168.1.195: seq=8 ttl=64 time=0.403 ms 64 bytes from 192.168.1.195: seq=9 ttl=64 time=0.406 ms 64 bytes from 192.168.1.195: seq=10 ttl=64 time=0.448 ms 64 bytes from 192.168.1.195: seq=11 ttl=64 time=0.399 ms 64 bytes from 192.168.1.195: seq=12 ttl=64 time=0.436 ms 64 bytes from 192.168.1.195: seq=13 ttl=64 time=0.438 ms 64 bytes from 192.168.1.195: seq=14 ttl=64 time=0.439 ms Does anybody has an idea what else cloud be wrong? Hauke
