Troy,
with the patch, now, it completely hangs.
The reason is that in timer_interrupt()
while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0)
{
Now that next_dec is unsigned, this condition is always false.
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.
--------------------------------------------
Jean-Denis Boyer, B.Eng., System Architect
Mediatrix Telecom Inc.
4229 Garlock Street
Sherbrooke (Québec)
J1L 2C8 CANADA
(819)829-8749 x241
--------------------------------------------
Hi Paul & Gabriel !
We indeed have some weird stuff mixing signed & unsigned in the
arch/ppc/kernel/time.c code. The patch enclosed, from Jean-Denis
Boyer, seems the right fix, except for one thing: I'd rather
change the test from >= to > (which in the old could would mean
changing the while (... < 0 to <= 0) as I see no reason to trigger
a new decrementer interrupt in ... 0 ticks !
Can you confirm it's ok to push ?
Regards,
Ben.
Troy,
with the patch, now, it completely hangs.
The reason is that in timer_interrupt()
while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0)
{
Now that next_dec is unsigned, this condition is always false.
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.
--------------------------------------------
Jean-Denis Boyer, B.Eng., System Architect
Mediatrix Telecom Inc.
4229 Garlock Street
Sherbrooke (Québec)
J1L 2C8 CANADA
(819)829-8749 x241
--------------------------------------------
On Wed, 8 May 2002, Benjamin Herrenschmidt wrote:
Hi Paul & Gabriel !
We indeed have some weird stuff mixing signed & unsigned in the
arch/ppc/kernel/time.c code. The patch enclosed, from Jean-Denis
Boyer, seems the right fix, except for one thing: I'd rather
change the test from >= to > (which in the old could would mean
changing the while (... < 0 to <= 0) as I see no reason to trigger
a new decrementer interrupt in ... 0 ticks !
This was done on purpose in case the decrementer is way slower than the
processor. It's nitpicking but I believed that some processors have a very
slow decrementer (in this case a true fractional phaselock would be
necessary to get the HZ you want with some precision).
Can you confirm it's ok to push ?
I'm not yet sure. I don't understand what happened in the first place.
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.
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.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/