bug#153: [kernel] bug#153: 2.4.14-SMP has no time

X-PA-RISC Linux-PR-Message: report 153
X-PA-RISC Linux-PR-Package: kernel
X-Loop: daniel_frazier@hp.com
Received: via spool by 153-bugs@bugs.parisc-linux.org id=B153.100671996018104
          (code B ref 153); Sun, 25 Nov 2001 20:33:01 GMT
Message-Id: <200111252021.NAA02365@puffin.external.hp.com>
To: Matthew Wilcox <willy@debian.org>, 153@bugs.parisc-linux.org
In-Reply-To: Message from kernel-admin@lists.parisc-linux.org 
   of "Sat, 24 Nov 2001 12:59:45 MST." <200111241959.MAA26577@puffin.external.hp.com> 
Date: Sun, 25 Nov 2001 13:21:05 -0700
From: Grant Grundler <grundler@puffin.external.hp.com>

> even running a while(1) ; hog shows 0 time taken.  i suspect
> update_process_times is not being called (ever).

update_process_times() *should* be getting called:
timer_interrupt() -> smp_do_timer() -> update_process_times()

If do_timer() is invoked (ie nticks > 0), then smp_do_time() is
called as well.  It's possible nticks == 0 since we have the
following code in time.c:

...
gettimeoffset (void)
{
#ifndef CONFIG_SMP
        /*
         * FIXME: This won't work on smp because jiffies are updated by cpu 0.
         *    Once parisc-linux learns the cr16 difference between processors,
         *    this could be made to work.
         */
....
#else
        return 0;
#endif
}

Not sure yet if that's the problem really...need to work this out more.
It's possible the "nticks=0" assignment in timer_interrupt() should
really be "nticks=1" since we in fact are processing the next tick.

thanks,
grant