linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] what should 'uptime' be on suspend?
@ 2007-07-20  2:42 Bill Davidsen
  2007-07-20 17:17 ` Ken Moffat
  0 siblings, 1 reply; 10+ messages in thread
From: Bill Davidsen @ 2007-07-20  2:42 UTC (permalink / raw)
  To: Linux Kernel M/L

I just found a machine which will resume after suspend to memory, using 
the mainline kernel (no suspend2 patch).

On resume I was looking at the uptime output, and it was about six 
minutes, FAR longer than the time since resume. So the topic for 
discussion is, should the uptime be
 - time sine the original boot
 - total uptime since first boot, not counting the time suspended
 - time since resume
 - some other time around six minutes

Any of the first three could be useful and "right" for some casesm thus 
discussion invited.

-- 
Bill Davidsen <davidsen@tmr.com>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20  2:42 [RFC] what should 'uptime' be on suspend? Bill Davidsen
@ 2007-07-20 17:17 ` Ken Moffat
  2007-07-20 17:42   ` Randy Dunlap
  0 siblings, 1 reply; 10+ messages in thread
From: Ken Moffat @ 2007-07-20 17:17 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Linux Kernel M/L

On Thu, Jul 19, 2007 at 10:42:22PM -0400, Bill Davidsen wrote:
> I just found a machine which will resume after suspend to memory, using 
> the mainline kernel (no suspend2 patch).
> 
> On resume I was looking at the uptime output, and it was about six 
> minutes, FAR longer than the time since resume. So the topic for 
> discussion is, should the uptime be
> - time sine the original boot
> - total uptime since first boot, not counting the time suspended
> - time since resume
> - some other time around six minutes
> 
> Any of the first three could be useful and "right" for some casesm thus 
> discussion invited.
> 
 My ibook has always been able to suspend to RAM.  For a long while,
uptime was shown as the time since the last boot.  At some point,
maybe about a year ago, this was "corrected" to show time since boot
_less_ time suspended.

 To be clear, the ibook suspends when I close the lid and resumes
when I open it.  Uptime used to be convenient, because I could work
out when I'd last booted.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20 17:17 ` Ken Moffat
@ 2007-07-20 17:42   ` Randy Dunlap
  2007-07-20 17:57     ` Ken Moffat
  2007-07-25 13:59     ` Pavel Machek
  0 siblings, 2 replies; 10+ messages in thread
From: Randy Dunlap @ 2007-07-20 17:42 UTC (permalink / raw)
  To: Ken Moffat; +Cc: Bill Davidsen, Linux Kernel M/L

On Fri, 20 Jul 2007 18:17:29 +0100 Ken Moffat wrote:

> On Thu, Jul 19, 2007 at 10:42:22PM -0400, Bill Davidsen wrote:
> > I just found a machine which will resume after suspend to memory, using 
> > the mainline kernel (no suspend2 patch).
> > 
> > On resume I was looking at the uptime output, and it was about six 
> > minutes, FAR longer than the time since resume. So the topic for 
> > discussion is, should the uptime be
> > - time sine the original boot
> > - total uptime since first boot, not counting the time suspended
> > - time since resume
> > - some other time around six minutes
> > 
> > Any of the first three could be useful and "right" for some casesm thus 
> > discussion invited.
> > 
>  My ibook has always been able to suspend to RAM.  For a long while,
> uptime was shown as the time since the last boot.  At some point,
> maybe about a year ago, this was "corrected" to show time since boot
> _less_ time suspended.
> 
>  To be clear, the ibook suspends when I close the lid and resumes
> when I open it.  Uptime used to be convenient, because I could work
> out when I'd last booted.

man uptime:
	uptime - tell how long the system has been running

I claim that the system is not running when it is suspended,
so the suspension time should not be included in uptime.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20 17:42   ` Randy Dunlap
@ 2007-07-20 17:57     ` Ken Moffat
  2007-07-20 21:49       ` Rafael J. Wysocki
  2007-07-21 13:54       ` Bill Davidsen
  2007-07-25 13:59     ` Pavel Machek
  1 sibling, 2 replies; 10+ messages in thread
From: Ken Moffat @ 2007-07-20 17:57 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Bill Davidsen, Linux Kernel M/L

On Fri, Jul 20, 2007 at 10:42:15AM -0700, Randy Dunlap wrote:
> 
> man uptime:
> 	uptime - tell how long the system has been running
> 
> I claim that the system is not running when it is suspended,
> so the suspension time should not be included in uptime.
> 
 So, maybe I shouldn't have put corrected in inverted commas,
because this was a real correction and my previous usage was an
unintended side-effect of an error.

 Anyway, the current behaviour is known and I guess any attempt to
change it (e.g. to what Bill was expecting) won't be well received.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20 17:57     ` Ken Moffat
@ 2007-07-20 21:49       ` Rafael J. Wysocki
  2007-07-21 13:54       ` Bill Davidsen
  1 sibling, 0 replies; 10+ messages in thread
From: Rafael J. Wysocki @ 2007-07-20 21:49 UTC (permalink / raw)
  To: Ken Moffat; +Cc: Randy Dunlap, Bill Davidsen, Linux Kernel M/L

On Friday, 20 July 2007 19:57, Ken Moffat wrote:
> On Fri, Jul 20, 2007 at 10:42:15AM -0700, Randy Dunlap wrote:
> > 
> > man uptime:
> > 	uptime - tell how long the system has been running
> > 
> > I claim that the system is not running when it is suspended,
> > so the suspension time should not be included in uptime.
> > 
>  So, maybe I shouldn't have put corrected in inverted commas,
> because this was a real correction and my previous usage was an
> unintended side-effect of an error.
> 
>  Anyway, the current behaviour is known and I guess any attempt to
> change it (e.g. to what Bill was expecting) won't be well received.

I agree.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20 17:57     ` Ken Moffat
  2007-07-20 21:49       ` Rafael J. Wysocki
@ 2007-07-21 13:54       ` Bill Davidsen
  2007-07-21 16:29         ` Ken Moffat
  2007-07-25 14:02         ` Pavel Machek
  1 sibling, 2 replies; 10+ messages in thread
From: Bill Davidsen @ 2007-07-21 13:54 UTC (permalink / raw)
  To: Ken Moffat; +Cc: Randy Dunlap, Linux Kernel M/L

Ken Moffat wrote:
> On Fri, Jul 20, 2007 at 10:42:15AM -0700, Randy Dunlap wrote:
>   
>> man uptime:
>> 	uptime - tell how long the system has been running
>>
>> I claim that the system is not running when it is suspended,
>> so the suspension time should not be included in uptime.
>>
>>     
>  So, maybe I shouldn't have put corrected in inverted commas,
> because this was a real correction and my previous usage was an
> unintended side-effect of an error.
>
>  Anyway, the current behaviour is known and I guess any attempt to
> change it (e.g. to what Bill was expecting) won't be well received.
>   

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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-21 13:54       ` Bill Davidsen
@ 2007-07-21 16:29         ` Ken Moffat
  2007-07-23 15:44           ` Bill Davidsen
  2007-07-25 14:02         ` Pavel Machek
  1 sibling, 1 reply; 10+ messages in thread
From: Ken Moffat @ 2007-07-21 16:29 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Randy Dunlap, Linux Kernel M/L

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.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-21 16:29         ` Ken Moffat
@ 2007-07-23 15:44           ` Bill Davidsen
  0 siblings, 0 replies; 10+ messages in thread
From: Bill Davidsen @ 2007-07-23 15:44 UTC (permalink / raw)
  To: Ken Moffat; +Cc: Randy Dunlap, Linux Kernel M/L

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-20 17:42   ` Randy Dunlap
  2007-07-20 17:57     ` Ken Moffat
@ 2007-07-25 13:59     ` Pavel Machek
  1 sibling, 0 replies; 10+ messages in thread
From: Pavel Machek @ 2007-07-25 13:59 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Ken Moffat, Bill Davidsen, Linux Kernel M/L

Hi!

> > > I just found a machine which will resume after suspend to memory, using 
> > > the mainline kernel (no suspend2 patch).
> > > 
> > > On resume I was looking at the uptime output, and it was about six 
> > > minutes, FAR longer than the time since resume. So the topic for 
> > > discussion is, should the uptime be
> > > - time sine the original boot
> > > - total uptime since first boot, not counting the time suspended
> > > - time since resume
> > > - some other time around six minutes
> > > 
> > > Any of the first three could be useful and "right" for some casesm thus 
> > > discussion invited.
> > > 
> >  My ibook has always been able to suspend to RAM.  For a long while,
> > uptime was shown as the time since the last boot.  At some point,
> > maybe about a year ago, this was "corrected" to show time since boot
> > _less_ time suspended.
> > 
> >  To be clear, the ibook suspends when I close the lid and resumes
> > when I open it.  Uptime used to be convenient, because I could work
> > out when I'd last booted.
> 
> man uptime:
> 	uptime - tell how long the system has been running
> 
> I claim that the system is not running when it is suspended,
> so the suspension time should not be included in uptime.

Well. I claim that the system is not running when cpu is in hlt.

...and on some weird machines (openmoko, olpc) they have hardware capable of
suspending most of machine between keypresses. Now, PCs are not there
yet, but sooner or later we will sleep/suspend between keypresses.

It is not worth changing now, but at least runtime suspend should
be accounted as 'running'.
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC] what should 'uptime' be on suspend?
  2007-07-21 13:54       ` Bill Davidsen
  2007-07-21 16:29         ` Ken Moffat
@ 2007-07-25 14:02         ` Pavel Machek
  1 sibling, 0 replies; 10+ messages in thread
From: Pavel Machek @ 2007-07-25 14:02 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Ken Moffat, Randy Dunlap, Linux Kernel M/L

On Sat 2007-07-21 09:54:37, Bill Davidsen wrote:
> Ken Moffat wrote:
> >On Fri, Jul 20, 2007 at 10:42:15AM -0700, Randy Dunlap 
> >wrote:
> >  
> >>man uptime:
> >>	uptime - tell how long the system has been running
> >>
> >>I claim that the system is not running when it is 
> >>suspended,
> >>so the suspension time should not be included in 
> >>uptime.
> >>
> >>    
> > So, maybe I shouldn't have put corrected in inverted 
> > commas,
> >because this was a real correction and my previous 
> >usage was an
> >unintended side-effect of an error.
> >
> > Anyway, the current behaviour is known and I guess any 
> > attempt to
> >change it (e.g. to what Bill was expecting) won't be 
> >well received.
> >  
> 
> 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.

Ouch, seems like something is wrong with timer subsystem. Can you
verify that rest of the clock machinery behaves ok?

We do manual correction of uptime during resume (IIRC) - perhaps
something goes wrong there?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2007-07-25 18:31 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-20  2:42 [RFC] what should 'uptime' be on suspend? Bill Davidsen
2007-07-20 17:17 ` Ken Moffat
2007-07-20 17:42   ` Randy Dunlap
2007-07-20 17:57     ` Ken Moffat
2007-07-20 21:49       ` Rafael J. Wysocki
2007-07-21 13:54       ` Bill Davidsen
2007-07-21 16:29         ` Ken Moffat
2007-07-23 15:44           ` Bill Davidsen
2007-07-25 14:02         ` Pavel Machek
2007-07-25 13:59     ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).