[parisc-linux] travel backwards in time?

[parisc-linux] travel backwards in time?

[Randolph Chung]

Recently Grant and I have observed several hangs in do_gettimeofday on a
c3k running 32 or 64-bit kernels (UP). 

The symptom we see is gettimeoffset returns a negative number which
results in a huge (unsigned) usec offset in do_gettimeofday, which ends
up spinning in a while loop.

On further investigation we found this piece of code that we don't 
quite understand in the gettimeoffset function:


        /* this is the intended time of the next tick */
        last_tick = cpu_data[smp_processor_id()].it_value;
        /* so subtract one tick */
        /* and account for possible difference between wall and actual time */
        last_tick += clocktick * (jiffies - wall_jiffies - 1);
	
The last_tick adjustment looks a bit odd. Looking at ia64, it looks more
like this:

        last_tick -= clocktick * (jiffies - wall_jiffies + 1);

I tried this and couldn't reproduce the hangs anymore, but am not sure
if this is the right fix.

jsm suggested we try an experiment to disable interrupts in the
timer_interrupt handler. I tried that yesterday (add a __cli() call) and
it didn't seem to fix the hangs.

Can someone more familiar with that part of the code (pb?) please comment?

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] travel backwards in time?

[Paul Bame]

> 
> Can someone more familiar with that part of the code (pb?) please comment?
> 

I never had lots of confidence in that code even though I introduced it
by distilling other archs -- and dimly recall not being able to use
ia64 for some reason, or maybe I'm remembering wrong.  I never felt
I completely understood the interaction with the sometimes-missed
timer interrupt and arch-independent timer handling, and some of the
other archs seemed to be unexpectedly different from each other.

How's that for a useless comment?! :-)

	-P

Re: [parisc-linux] travel backwards in time?

[Grant Grundler]

Randolph Chung wrote:
> Recently Grant and I have observed several hangs in do_gettimeofday on a
> c3k running 32 or 64-bit kernels (UP). 
> 
> The symptom we see is gettimeoffset returns a negative number which
> results in a huge (unsigned) usec offset in do_gettimeofday, which ends
> up spinning in a while loop.
...
> The last_tick adjustment looks a bit odd. Looking at ia64, it looks more
> like this:
> 
>         last_tick -= clocktick * (jiffies - wall_jiffies + 1);

For the record, this fix was committed in one of the 2.4.14-pa5
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2001-November/030021.html

I'm still not 100% certain all our time keeping code is correct.
But I'm comfortable this patch fixes the problem we saw and
does not introduce any new ones.

grant

[parisc-linux] 2.4.16-pa12 broken on c3000

[Randolph Chung]

Looks like -pa12 enabled some #if 0 code in arch/parisc/mm/init.c that
is causing things to die. Both Grant and I saw ifconfig abort when
the free_initmem code was enabled. Reverting back to 1.43 worked for
me...

Looks like Helge checked that in.. Helge, can you please take a look?

Soft power is very cool though! :-)

thanks,
randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] 2.4.16-pa12 broken on c3000

[Grant Grundler]

[ old news - cleaning out my inbox ]

Randolph Chung wrote:
> Looks like -pa12 enabled some #if 0 code in arch/parisc/mm/init.c that
> is causing things to die. Both Grant and I saw ifconfig abort when
> the free_initmem code was enabled. Reverting back to 1.43 worked for
> me...

Fixed. my bad. removed __init in PCI config space code path.

FYI, IOAQ pointed at the culprit: lba_device_present()
Should make debugging this kind of problem easy.

grant