Re: Bogomips and loops_per_jiffy

quoted

quoted

while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0)
{

Now that next_dec is unsigned, this condition is always false.

Yes I wrote this in the most possible compact way.  But I don't understand
(yet) how this can cause problems. You have a security margin of about 2
billion timbase ticks.

The problem occurs when calibrating the delay loop, and the timebase is
very large.

http://lists.linuxppc.org/linuxppc-embedded/200205/msg00040.html

We could probably just avoid all this and do 'set_tb(0,0)' in time_init
(since we go and try to sync the timebase on SMP systems anyway)

quoted

quoted

Here is another patch I suggest to replace yours.
Its in attachement to this email.
I tested it, and it seems OK.

I did not include your modification made to the type of local variables in
function do_settimeofday().
I do not see how it is related to our problem.

That one is better for symmetry between gettimeofday and settimeofay,
but OTOH the types in the timeval structures are defined as signed.
(Wrongly IMHO)

Could you please decribe exactly the problem or forward me the messages.
(Which machine, processor and compiler just in case). It seems that I have
been automagically dropped from linuxppc-embedded, unfortunately!

	Regards,
	Gabriel.

P.S: please try to get patches attached as text. It appears as
Application/BINARY which is quite annoying.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Thu, 9 May 2002, Troy Benjegerdes wrote:

quoted

quoted

quoted

while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0)
{

Now that next_dec is unsigned, this condition is always false.

Yes I wrote this in the most possible compact way.  But I don't understand
(yet) how this can cause problems. You have a security margin of about 2
billion timbase ticks.

The problem occurs when calibrating the delay loop, and the timebase is
very large.

The fact that the TB is large or not should be irrelevanet, after all
the TB wraps around every 2 to 5 minutes or so on most processors. Do the
math, it's rather simple modulo 2^32 arithmetic. If I lost decrementer
interrupts every time the TB wraps around, I would see strange things
under top for example.

Now if you do a set_tb after the time_init at some point, you have to
update the timekeeping variables (jiffy_stamp or whatever) in sync.
Otherwise you are going to have problems.

Note that there is a very simple possible patch: truncate the new value
you load into the decrementer to tb_ticks_per_jiffy. And for debugging,
keep the last few values of the timebase at the decrementer interrupt
around and print them when you have to truncate. I'm afraid that this is a
symptom of lost timekeeping after reading the RTC and that you simply
cure the symptom.

http://lists.linuxppc.org/linuxppc-embedded/200205/msg00040.html

We could probably just avoid all this and do 'set_tb(0,0)' in time_init
(since we go and try to sync the timebase on SMP systems anyway)

Better set the TB to a large value to force the problem and see if you can
reproduce it.

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/