Ken Moffat wrote:
On Sat, Jul 21, 2007 at 09:54:37AM -0400, Bill Davidsen wrote:
So is setting it to a random number considered correct behavior? Any of
the first three values I mentioned would make sense, but the value I see
is neither time since resume, time since power-on to do the resume, or
any of the logical uptime values. That was the whole point of the
original post, the uptime reported makes no sense at all.
I assumed you had booted for a short time, suspended, resumed, and
then noticed the uptime was longer than time since resume.
If you think there is a bug it might help to do a cold boot, at
some point note uptime and then immediately suspend, resume some time
later, immediately note uptime (including local time), keep it
running, and later monitor uptime against local time (i.e. the local
time will let you know the change you expect to see in uptime). You
might also want to confirm that the local time is maintained
correctly.
I resumed this morning, uptime before the suspend was ~4 hours, suspend
time was ~30 hours, resume took 76 sec from power-on, uptime was 2m56s.
As originally noted, the first time I did this the "uptime" after resume
was 6+min. First noted on suspend to ram, this was suspend to disk to
see if that changed anything.
Just an oddity, I guess if I care I can track it myself.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
