On Thu, 2 Mar 2000, Boris Okun wrote:
>I don't mean do_slow_gettimeoffset is erroneous, I mean doing lost_ticks
>after it is wrong. See below.
Doing lost_ticks after slow_gettimeoffset is correct and necessary.
>Perhaps I was not clear. do_settimeofday() does call
>do_gettimeoffset(), but lost_ticks code is not called, it's in the
>do_gettimeofday().
>I think IA64 has this right and IA32 has it wrong.
That's right, it's a plain minor bug.
>What is fftw?
www.fftw.org
>Whether tsc_low overflows in 10ms depends on it's value in the beginning
>of this 10ms.
It doesn't matter the value at the beginning of 10msec.
>> so we still have a few years before we need to use the high part ;). On a
>> mean 500mhz cpu it takes around 8 seconds to overflow the low tsc a
>> 8seconds is more than enough for IA32 CPUs.
>>
>
>But my point is that I sometimes see delta_tsc=tsc_current-tsc_last of
>order 10^7--10^8 and the current code does not get it right (Hmm, have
>to think about this, confused).
So your TSC is are getting crazy or they are not in sync.
>I have no problems in UP stock 2.3.47.
Ok so your second TSC have some trouble.
>My current theory is that lost_ticks are wrong with get_slow_timeoffset.
That's not the case. lost_ticks is necessary for both slow and fast
gettimeoffset.
>And for per processor tsc's I'll need per processor lost_ticks.
No, lost_ticks has only to deal with the timer interrupt, timer chip latch
and with the xtime settings. It has anything to do with the TSC or with
SMP.
>That would explain why disabling global lost_ticks makes things better.
It make no sense to me that it makes things better.
Since UP works fine despite of the other tests it can only be the TSC of
your second CPU that has hardware troubles even if it's not clear why
using slow_gettimeoffset didn't helped. Certainly there was something
wrong in the changes.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:13 EST