What we wound up doing was splitting tvtohz() into two functions.
tvtohz_high(tv)
Returned value meets or exceeds requested time. A minimum value
of 1 is returned (really only for {0,0}.. else minimum value is 2).
tvtohz_low(tv)
Returned value might be
On Thu, 10 Sep 2009, John Baldwin wrote:
$ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
at different HZ values and some back of the envelope calculations
one could even determine estimate the frequency and duration
of those SMI interrupts!
On recent motherboards I have
On Thu, Sep 10, 2009 at 11:02:19PM +0930, Daniel O'Connor wrote:
On Thu, 10 Sep 2009, John Baldwin wrote:
$ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
at different HZ values and some back of the envelope calculations
one could even determine estimate the frequency and
On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
[Note 3] the TSC frequency is computed reading the tsc around a
call to DELAY(100) and assuming
On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote:
On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
[Note 3] the TSC frequency is computed reading
On Wednesday 09 September 2009 4:32:16 pm Luigi Rizzo wrote:
On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote:
On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
On Sunday 06 September 2009 11:51:54 am
On Wed, Sep 09, 2009 at 04:42:05PM -0400, John Baldwin wrote:
...
It would explain why it gets better later since the uhci(4), ohci(4) and
ehci(4) drivers disable the SMI# interrupts while attaching to the
controllers.
ok makes sense -- if the SMI interrupts last longer than 1/HZ
On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
[Note 3] the TSC frequency is computed reading the tsc around a
call to DELAY(100) and assuming that the i8254 runs
at the nominal rate, 1.193182 MHz.
From tests I have made, the measurement in init_TSC()
On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
[Note 3] the TSC frequency is computed reading the tsc around a
call to DELAY(100) and assuming that the i8254 runs
at the nominal rate, 1.193182 MHz.
On Sun, Sep 06, 2009 at 05:36:29PM -0700, Peter Wemm wrote:
On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzori...@iet.unipi.it wrote:
(this problem seems to affect both current and -stable,
so let's see if here i have better luck)
I just noticed [Note 1,2] that when setting HZ 2500 (even if
On Mon, Sep 07, 2009 at 09:21:59AM +0200, Luigi Rizzo wrote:
On Sun, Sep 06, 2009 at 05:36:29PM -0700, Peter Wemm wrote:
On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzori...@iet.unipi.it wrote:
(this problem seems to affect both current and -stable,
so let's see if here i have better luck)
Hi, all--
On Sep 7, 2009, at 12:21 AM, Luigi Rizzo wrote:
3. ?CAUSE an error in tvtohz(), reported long ago in
? ? ? ?http://www.dragonflybsd.org/presentations/nanosleep/
? ? ? ?which causes a systematic error of an extra tick in the
computation
? ? ? ?of the sleep times.
? ?FIX: the above
(this problem seems to affect both current and -stable,
so let's see if here i have better luck)
I just noticed [Note 1,2] that when setting HZ 2500 (even if it is
an exact divisor of the APIC/CPU clock) there is a significant
drift between the delays generated by usleep()/select() and those
On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzori...@iet.unipi.it wrote:
(this problem seems to affect both current and -stable,
so let's see if here i have better luck)
I just noticed [Note 1,2] that when setting HZ 2500 (even if it is
an exact divisor of the APIC/CPU clock) there is a
14 matches
Mail list logo
