On Thu, 2002-12-19 at 15:36, Todd Poynor wrote:

Suggest more unique names for these globals.

Well, how about making them static? :)

+       jiffies += rtc_secs_elapsed * HZ;

If jiffies is jumped forward then can kernel events (such as those
waiting on a kernel timer) be missed?

I certainly *hope* the check is >= rather than == ... :)

Whether or not timer queues et al
are processed on wakeup, not sure if it's harmful to update the "kernel
time" when the kernel has done nothing during the sleep interval, maybe
causing various timeouts.  Has this been tried with applications like X
running and verified not to kill apps on wakeup?

I have not run anything interesting like X, no.

Matt Locke and I have been discussing whether it's best to update wall
clock time but leave jiffies alone, since "kernel time" did not advance
during the sleep interval.  It's a little worrisome: the kernel advances
time by 10ms for its own operations, but wallclock time (xtime and RTC)
jumps forward 10 minutes.  We've tried this a little bit on a TI OMAP
and haven't seen anything die so far, but I imagine there'll be some
application that isn't happy about the situation no matter what choice
is made.

Before posting I had tried commenting out the jiffies update and it
seemed to run ok both ways. I decided to leave it in though to preserve
the reality of time passing as much as possible.
arch/arm/mach-sa1100/pm.c seems to only update xtime.tv_sec. I'm hoping
Someone Who Knows will comment one way or the other here...

The updated patch, with many cleanups and one important bugfix, has been
posted to http://penguinppc.org/~hollis/405LP-sleep.diff. Aside from the
remaining get_pteptr problem, I think the code is ready to be checked
in. If anyone disagrees please let me know. :)

-Hollis
--
PowerPC Linux
IBM Linux Technology Center


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