> I tested your patch and it solved our problem 100%. There's no
> timedrift anymore.
>
> Do you think the patch will make it in 4.4R. ? We need it urgently.
I can confirm the solution to the time drift problem. Our Netfinity
5600 SMP servers with Serverworks LE chipset now stay nicely in sync.
Nobody's formally asked the release engineers yet. I'd want to see a
request sent to [EMAIL PROTECTED] in the usual way, with diffs attached,
before I'd decide either way.
- Jordan
From: Martin Blapp <[EMAIL PROTECTED]>
Subject: Re: Clock speedup on 4.X FreeBSD SMP and ser
> The other macros also have a space befor the semicolons :). Otherwise OK.
> Better commit this (especially to 4.4R) until we have something better.
I also think that this is important to have fixed. Without this fix,
we would have been forced to change the platform for our software to a
worki
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> > I see (amost).
> >
> > Please format the macro the same as the other macros in the file.
>
> Index: apic_vector.s
> ===
> RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
> retrie
> I remember this a bit better after reading my log message for rev.1.134
> of clock.c :-).
>
> At the time, the clock interrupt handler was not fast. However, it
> could be delayed for a while by a fast interrupt handler (it still
> can). Since it is delayed, it can't set clkintr_pending and w
On Fri, 31 Aug 2001, Leo Bicknell wrote:
> On Fri, Aug 31, 2001 at 12:48:12PM -0700, Julian Elischer wrote:
> > > value) although the result will still be monotonous.
> >
> >
> > hmm monotonus? That explains the sudden bursts of sleepiness I
> > occasionally get when seated in front of the
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> For RELENG_4, which uses Xintr0, this problem is reduced by adding the
> clkintr_pending variable (cf. revision 1.134 of clock.c and revision
> 1.38 of apic_vector.s)
>
> Looking more at the code, I now see that clkintr_pending is never set
> in -cur
On Fri, Aug 31, 2001 at 12:48:12PM -0700, Julian Elischer wrote:
> > value) although the result will still be monotonous.
>
>
> hmm monotonus? That explains the sudden bursts of sleepiness I
> occasionally get when seated in front of the terminal!
>
> (monatomicly increasing maybe?)
It incre
> I see (amost).
>
> Please format the macro the same as the other macros in the file.
Index: apic_vector.s
===
RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
retrieving revision 1.47.2.4
diff -u -r1.47.2.4 apic_vector.s
---
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
>
> > Hmm, does -current even need clkintr_pending anymore? What is its purpose?
>
> There is a problem if i8254_get_timecount locks clock_lock right
> before a rollover but reads the timer right afterwards. In that case,
> a too low value can be
> Hmm, does -current even need clkintr_pending anymore? What is its purpose?
There is a problem if i8254_get_timecount locks clock_lock right
before a rollover but reads the timer right afterwards. In that case,
a too low value can be returned (resulting in 1/Hz too small time
value) although
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> I wrote:
>
> > The problem here is that CPU#1 fails to hold clock_lock while setting
> > clkintr_pending, causing i8254_offset to be stepped twice, first due
> > to clkintr_pending, then due to i8254_lastcount being larger than count.
>
> With this p
On 31-Aug-01 [EMAIL PROTECTED] wrote:
>
> I wrote:
>
>> The problem here is that CPU#1 fails to hold clock_lock while setting
>> clkintr_pending, causing i8254_offset to be stepped twice, first due
>> to clkintr_pending, then due to i8254_lastcount being larger than count.
>
> The correspondin
tor, will you commit this?
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
>
> I wrote:
>
> > The problem here is that CPU#1 fails to hold clock_lock while setting
> > clkintr_pending, causing i8254_offset to be stepped twice, first due
> > to clkintr_pending, then due to i8254_lastcount being l
Hi,
I tested your patch and it solved our problem 100%. There's no
timedrift anymore.
Do you think the patch will make it in 4.4R. ? We need it urgently.
Thanks a lot for your analysis and your fast work !
Martin
> --- apic_vector.s.old Fri Mar 2 13:47:31 2001
> +++ apic_vector.s Fri Au
I wrote:
> The problem here is that CPU#1 fails to hold clock_lock while setting
> clkintr_pending, causing i8254_offset to be stepped twice, first due
> to clkintr_pending, then due to i8254_lastcount being larger than count.
With this patch applied to RELENG_4, the clock speedup seems to disa
> --- sys/i386/isa/clock.cThu Aug 30 17:01:31 2001
> +++ sys/i386/isa/clock.c.newThu Aug 30 17:01:29 2001
> @@ -1203,7 +1203,7 @@
> high = inb(TIMER_CNTR0);
> count = timer0_max_count - ((high << 8) | low);
> if (count < i8254_lastcount ||
> - (!i8254
Hi,
Together with Thomas Moestel, I have found that the following patch
seems to solve the gettimeofday() problem and stops the time drift:
--- sys/i386/isa/clock.cThu Aug 30 17:01:31 2001
+++ sys/i386/isa/clock.c.newThu Aug 30 17:01:29 2001
@@ -1203,7 +1203,7 @@
high = inb(
On Thu, 30 Aug 2001, Martin Blapp wrote:
> Searching the freebsd mailinglists I have seen that you also suffering
> under this problem on 4.X. STABLE:
I now remember your old mail about this. I (implicitly) suggested a fix,
but apparently no one tried it:
> On Thu, 21 Jun 2001, Martin Blapp wr
In a message dated 8/30/01 7:44:23 AM Eastern Daylight Time, [EMAIL PROTECTED] writes:
> Searching the freebsd mailinglists I have seen that you also suffering
> under this problem on 4.X. STABLE:
>
> I have isolated the problem to be due reading the time with microtime()
>
> Execute this
Hi,
Searching the freebsd mailinglists I have seen that you also suffering
under this problem on 4.X. STABLE:
I have isolated the problem to be due reading the time with microtime()
Execute this programm:
#include
#include
#include
int
main(void)
{
for(;;) {
struct
21 matches
Mail list logo
