Re: select() returning early from timeouts ? (on qemu, HEAD and RELENG_8)

In article <20091226154604.GA6932@xxxxxxxxxxxxxxxxxxxx> you write:
Hi,
Hi!

while doing some tests with picobsd images on qemu, i noticed
that "ping" runs too fast (approx every 0.4s instead of 1s)
Upon investigation, the problem seems related to
retval = select(..., &timeout)
returning a retval of 0 way before the timeout has elapsed
(at least, according to a gettimeofday which is run right after).

My host system is FreeBSD 7.2-stable i386 with qemu.
In the guest (which is built using picobsd 'bridge') i set
kern.timecounter.hardware=i8254
A guest based on RELENG_7 works fine, whereas HEAD and RELENG_8
exhibit the problem.
Easy way to check:

time ping -c 21 localhost
(or, on picobsd "date; ping -c 21 localhost; date" )

you should see a real time of 20 seconds (I see 8s on my system).

I was wondering if someone can try the above on real hardware
and let me know.

Even if just related to qemu or some ACPI/timecounter config, it
would be good to know where this comes from.

BTW I don't think this is related to the bug reported in september
of timeouts firing one tick late.

I am going to try various HEAD versions to see where the issue came
out, but it might be a bit time-consuming so if you have suggestions
on possible causes I'd be glad to know.

thanks
luigi

Just in case this is not expected: I can't reproduce this issue on a
FreeBSD iapetus.kn-bremen.de 7.2-STABLE FreeBSD 7.2-STABLE #1: Sun Jun 21 00:36:42 CEST 2009 nox@xxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/home/nox/src72s/src/sys/IAPETUS amd64
host, at least with FreeBSD-9.0-HEAD-20091226-JPSNAP-i386-dvd1.iso,
9.0-HEAD-20091123-JPSNAP-i386-dvd1.iso and 8.0-RELEASE-i386-dvd1.iso
guests in livefs (fixit->cdrom/dvd), qemu 0.11.0, host kern.hz=1000,
and guest kern.hz=100 (which the guest kernel automagically goes down
to when running in a VM since 8.0.)

% qemu -m 256 -cdrom FreeBSD-9.0-HEAD-20091226-JPSNAP-i386-dvd1.iso -curses
[...]
Fixit# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: HPET -> i8254
Fixit# ifconfig lo0 127.1
Fixit# time ping -c5 127.1
PING 127.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=5.095 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.380 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.370 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.342 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.327 ms

--- 127.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.327/1.303/5.095/1.896 ms
4.06 real 0.02 user 0.08 sys
Fixit# time sleep 4
4.04 real 0.00 user 0.03 sys
Fixit# vmstat -i
interrupt total rate
irq1: atkbd0 259 4
irq4: uart0 1 0
irq15: ata1 631 11
cpu0: timer 21362 403
Total 22253 419
Fixit# sysctl kern.hz
kern.hz: 100
Fixit#

And If I boot the host with kern.hz=100 too I get the expected 1/4
guest timer slowdown (cpu0: timer only runs at 100 Hz when in fact it
wants 400 Hz) unless I disable the guest's apic. (As also now noted
in the qemu port's pkg-message.)

HTH,
Juergen

PS: I got the snapshot isos from here in case you don't know it:
http://pub.allbsd.org/FreeBSD-snapshots/
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"