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

On Sat, Dec 26, 2009 at 12:56:49PM -0500, b. f. wrote:
> >I was wondering if someone can try the above on real hardware
> >and let me know.
> 
> 
> 9-CURRENT amd64 r r200984M
> legacy usb support off in bios
> >From loader.conf:
> kern.hz="100"
> hint.apic.0.clock="0"
> hint.atrtc.0.clock="0"
> >From sysctl.conf:
> kern.timecounter.hardware=i8254
> 
> sysctl shows:
> kern.clockrate: { hz = 100, tick = 10000, profhz = 100, stathz = 100 }
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC(800) HPET(900) ACPI-fast(1000) i8254(0)
> dummy(-1000000)
> kern.timecounter.hardware: i8254
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.i8254.mask: 4294967295
> kern.timecounter.tc.i8254.counter: 1239934843
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.ACPI-fast.mask: 16777215
> kern.timecounter.tc.ACPI-fast.counter: 8027521
> kern.timecounter.tc.ACPI-fast.frequency: 3579545
> kern.timecounter.tc.ACPI-fast.quality: 1000
> kern.timecounter.tc.HPET.mask: 4294967295
> kern.timecounter.tc.HPET.counter: 519307291
> kern.timecounter.tc.HPET.frequency: 25000000
> kern.timecounter.tc.HPET.quality: 900
> kern.timecounter.tc.TSC.mask: 4294967295
> kern.timecounter.tc.TSC.counter: 4274176162
> kern.timecounter.tc.TSC.frequency: 800000000
> kern.timecounter.tc.TSC.quality: 800
> kern.timecounter.invariant_tsc: 0
> kern.hz: 100
> 
>  #time ping -c 21 localhost
> PING localhost... (127.0.0.1): 56 data bytes
> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.080 ms
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.037 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.036 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.032 ms
> 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.039 ms
> 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.072 ms
> 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.034 ms
> 64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=0.034 ms
> 64 bytes from 127.0.0.1: icmp_seq=11 ttl=64 time=0.032 ms
> 64 bytes from 127.0.0.1: icmp_seq=12 ttl=64 time=0.041 ms
> 64 bytes from 127.0.0.1: icmp_seq=13 ttl=64 time=0.038 ms
> 64 bytes from 127.0.0.1: icmp_seq=14 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=15 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=16 ttl=64 time=0.032 ms
> 64 bytes from 127.0.0.1: icmp_seq=17 ttl=64 time=0.032 ms
> 64 bytes from 127.0.0.1: icmp_seq=18 ttl=64 time=0.032 ms
> 64 bytes from 127.0.0.1: icmp_seq=19 ttl=64 time=0.033 ms
> 64 bytes from 127.0.0.1: icmp_seq=20 ttl=64 time=0.069 ms
> 
> --- localhost... ping statistics ---
> 21 packets transmitted, 21 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.032/0.040/0.080/0.014 ms
> 
> real    0m20.198s
> user    0m0.000s
> sys     0m0.002s
> 
> Apart from the possible emulation complications, the i8254 calibration
> code has been removed, and there was some discussions about i8254
> problems back when you outlined your callout change proposal...

thanks a lot. Now I am doing a binary search to find the problematic
versions, unfortunately it takes almost 1hr for each attempt
between a buildworld and buildkernel (or picobsd equivalents..)
So far r190000 and r195000 work fine, and r200xxx has the bug.

cheers
luigi