[pm] fix time after suspend-to-*

[pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

This adds suspend/resume methods for time, so that real time is
refreshed from cmos when suspend is finished. Please apply,

							Pavel
[Code was copied from apm.c, someone familiar from apm.c can probably
kill it from there -- after adding device_power_down() and
device_power_up() to right places].

--- tmp/linux/arch/i386/kernel/time.c	2003-10-09 00:13:14.000000000 +0200
+++ linux/arch/i386/kernel/time.c	2003-10-23 01:05:36.000000000 +0200
@@ -271,16 +271,39 @@
 	unsigned long retval;
 
 	spin_lock(&rtc_lock);
-
 	retval = mach_get_cmos_time();
-
 	spin_unlock(&rtc_lock);
 
 	return retval;
 }
 
+static long clock_cmos_diff;
+static int got_clock_diff;
+
+static int pit_suspend(struct sys_device *dev, u32 state)
+{
+	/*
+	 * Estimate time zone so that set_time can update the clock
+	 */
+	clock_cmos_diff = -get_cmos_time();
+	clock_cmos_diff += get_seconds();
+	got_clock_diff = 1;
+	return 0;
+}
+
+static int pit_resume(struct sys_device *dev)
+{
+	if (got_clock_diff) {	/* Must know time zone in order to set clock */
+		xtime.tv_sec = get_cmos_time() + clock_cmos_diff;
+		xtime.tv_nsec = 0; 
+	} 
+	return 0;
+}
+
 static struct sysdev_class pit_sysclass = {
 	set_kset_name("pit"),
+	.resume = pit_resume,
+	.suspend = pit_suspend,
 };
 
 /* XXX this driverfs stuff should probably go elsewhere later -john */

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[john stultz]

On Wed, 2003-10-22 at 16:33, Pavel Machek wrote:
> Hi!
> 
> This adds suspend/resume methods for time, so that real time is
> refreshed from cmos when suspend is finished. Please apply,
> 

[snip]

>  
> +static long clock_cmos_diff;
> +static int got_clock_diff;
> +
> +static int pit_suspend(struct sys_device *dev, u32 state)
> +{
> +	/*
> +	 * Estimate time zone so that set_time can update the clock
> +	 */
> +	clock_cmos_diff = -get_cmos_time();
> +	clock_cmos_diff += get_seconds();
> +	got_clock_diff = 1;
> +	return 0;
> +}
> +
> +static int pit_resume(struct sys_device *dev)
> +{
> +	if (got_clock_diff) {	/* Must know time zone in order to set clock */
> +		xtime.tv_sec = get_cmos_time() + clock_cmos_diff;
> +		xtime.tv_nsec = 0; 
> +	} 
> +	return 0;
> +}
> +
>  static struct sysdev_class pit_sysclass = {
>  	set_kset_name("pit"),
> +	.resume = pit_resume,
> +	.suspend = pit_suspend,
>  };

Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally
you need to have the xtime_lock to safely manipulate xtime. Also,
couldn't you just call settimeofday() instead?  The bit about manually
setting the timezone also confuses me, as we don't normally do this at
bootup in the kernel.  

thanks
-john

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > +static int pit_resume(struct sys_device *dev)
> > +{
> > +	if (got_clock_diff) {	/* Must know time zone in order to set clock */
> > +		xtime.tv_sec = get_cmos_time() + clock_cmos_diff;
> > +		xtime.tv_nsec = 0; 
> > +	} 
> > +	return 0;
> > +}
> > +
...
> Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally
> you need to have the xtime_lock to safely manipulate xtime. Also,
> couldn't you just call settimeofday() instead?  The bit about manually
> setting the timezone also confuses me, as we don't normally do this at
> bootup in the kernel.  
> 

I took it straight from apm.c... But it is well possible that it needs
some locking. OTOH this runs with interrupts disabled, perhaps
thats enough?
				Pavel
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: [pm] fix time after suspend-to-*

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
>>>+static int pit_resume(struct sys_device *dev)
>>>+{
>>>+	if (got_clock_diff) {	/* Must know time zone in order to set clock */
>>>+		xtime.tv_sec = get_cmos_time() + clock_cmos_diff;
>>>+		xtime.tv_nsec = 0; 
>>>+	} 
>>>+	return 0;
>>>+}
>>>+
> 
> ...
> 
>>Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally
>>you need to have the xtime_lock to safely manipulate xtime. Also,
>>couldn't you just call settimeofday() instead?  The bit about manually
>>setting the timezone also confuses me, as we don't normally do this at
>>bootup in the kernel.  
>>
> 
> 
> I took it straight from apm.c... But it is well possible that it needs
> some locking. OTOH this runs with interrupts disabled, perhaps
> thats enough?

I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly 
recommend that settimeofday() NOT be called.  It will try to adjust 
wall_to_motonoic, but, as this appears to be a correction for time lost while 
sleeping, wall_to_monotonic should not change.

As to locking, ints off for UP, but you need the full lock for SMP systems.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [pm] fix time after suspend-to-*

[john stultz]

On Thu, 2003-10-23 at 13:23, George Anzinger wrote:

> I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly 
> recommend that settimeofday() NOT be called.  It will try to adjust 
> wall_to_motonoic, but, as this appears to be a correction for time lost while 
> sleeping, wall_to_monotonic should not change.

While suspended should the notion monotonic time be incrementing? If
we're not incrementing jiffies, then uptime isn't being incremented, so
to me it doesn't follow that the monotonic time should be incrementing
as well. 

It may very well be a POSIX timers spec issue, but it just strikes me as
odd.

thanks
-john

Re: [pm] fix time after suspend-to-*

[George Anzinger]

john stultz wrote:
> On Thu, 2003-10-23 at 13:23, George Anzinger wrote:
> 
> 
>>I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly 
>>recommend that settimeofday() NOT be called.  It will try to adjust 
>>wall_to_motonoic, but, as this appears to be a correction for time lost while 
>>sleeping, wall_to_monotonic should not change.
> 
> 
> While suspended should the notion monotonic time be incrementing? If
> we're not incrementing jiffies, then uptime isn't being incremented, so
> to me it doesn't follow that the monotonic time should be incrementing
> as well. 

Uh, not moving jiffies?  What does this say about any timers that may be 
pending?  Say for cron or some such?  Like I said, I picked up this thread a bit 
late, but, seems to me that if time is passing, it should pass on both the 
jiffies AND the wall clocks.
> 
> It may very well be a POSIX timers spec issue, but it just strikes me as
> odd.

The spec thing would relate to any sleeps or timers that are pending.  The spec 
would seem to say they should complete somewhere near the requested wall time, 
but NEVER before.  By not moving jiffies, I think they will be a bit late.  Now, 
if they were to complete during the sleep, well those should fire at completion 
of the sleep.  If the are to complete after the sleep, then, it seems to me, 
they should fire at the requested time.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> >>I lost (never saw) the first of this thread, BUT, if this is 2.6, I 
> >>strongly recommend that settimeofday() NOT be called.  It will try to 
> >>adjust wall_to_motonoic, but, as this appears to be a correction for time 
> >>lost while sleeping, wall_to_monotonic should not change.
> >
> >
> >While suspended should the notion monotonic time be incrementing? If
> >we're not incrementing jiffies, then uptime isn't being incremented, so
> >to me it doesn't follow that the monotonic time should be incrementing
> >as well. 
> 
> Uh, not moving jiffies?  What does this say about any timers that may be 
> pending?  Say for cron or some such?  Like I said, I picked up this thread 
> a bit late, but, seems to me that if time is passing, it should pass on 
> both the jiffies AND the wall clocks.
> >
> >It may very well be a POSIX timers spec issue, but it just strikes me as
> >odd.
> 
> The spec thing would relate to any sleeps or timers that are pending.  The 
> spec would seem to say they should complete somewhere near the requested 
> wall time, but NEVER before.  By not moving jiffies, I think they will be a 
> bit late.  Now, if they were to complete during the sleep, well those 
> should fire at completion of the sleep.  If the are to complete after the 
> sleep, then, it seems to me, they should fire at the requested time.

We are currently not incrementing jiffies during sleep, so sleep seems
to be 

cli
wait a *long* time
sti

. Adjusting wall time is a must, but I hope to get away without
updating jiffies etc. At least that's how apm worked up to now (?).

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[john stultz]

On Thu, 2003-10-23 at 16:09, George Anzinger wrote:
> john stultz wrote:
> > On Thu, 2003-10-23 at 13:23, George Anzinger wrote:
> >>I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly 
> >>recommend that settimeofday() NOT be called.  It will try to adjust 
> >>wall_to_motonoic, but, as this appears to be a correction for time lost while 
> >>sleeping, wall_to_monotonic should not change.
> > 
> > While suspended should the notion monotonic time be incrementing? If
> > we're not incrementing jiffies, then uptime isn't being incremented, so
> > to me it doesn't follow that the monotonic time should be incrementing
> > as well. 
> 
> Uh, not moving jiffies?  What does this say about any timers that may be 
> pending?  Say for cron or some such?  Like I said, I picked up this thread a bit 
> late, but, seems to me that if time is passing, it should pass on both the 
> jiffies AND the wall clocks.

My understanding is that we are suspending the box (ie: putting your
laptop to sleep/hybernate), so for all practical purposes the box is off
waiting until it is woken up. During that time I don't believe we
receive timer interrupts. When we are woken up, we should update the
system time and continue, but as the box wasn't running during the
interim we shouldn't be increasing the notion of monotonic time. 

> > It may very well be a POSIX timers spec issue, but it just strikes me as
> > odd.
> 
> The spec thing would relate to any sleeps or timers that are pending.  The spec 
> would seem to say they should complete somewhere near the requested wall time, 
> but NEVER before.  By not moving jiffies, I think they will be a bit late.  Now, 
> if they were to complete during the sleep, well those should fire at completion 
> of the sleep.  If the are to complete after the sleep, then, it seems to me, 
> they should fire at the requested time.

Hmmm. That last sentence gives me pause. I guess it comes down to how
you request your timer expiration: in wall time or system time.  I
always thought it was in system time, but you know this stuff better
then I, so I'll defer.

Pavel: You new patch looks ok wrt the locking issue. I'm still pretty
suspicious of the clock_cmos_diff but I'll trust you that it does the
right thing (this has been tested, right? :)

thanks
-john

Re: [pm] fix time after suspend-to-*

[john stultz]

On Thu, 2003-10-23 at 17:29, john stultz wrote:
> When we are woken up, we should update the
> system time and continue, but as the box wasn't running during the
> interim we shouldn't be increasing the notion of monotonic time. 

Ack, that should be "update the wall time and continue".

Sorry.

thanks
-john

Re: [pm] fix time after suspend-to-*

[George Anzinger]

john stultz wrote:
> On Thu, 2003-10-23 at 16:09, George Anzinger wrote:
> 
>>john stultz wrote:
>>
>>>On Thu, 2003-10-23 at 13:23, George Anzinger wrote:
>>>
>>>>I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly 
>>>>recommend that settimeofday() NOT be called.  It will try to adjust 
>>>>wall_to_motonoic, but, as this appears to be a correction for time lost while 
>>>>sleeping, wall_to_monotonic should not change.
>>>
>>>While suspended should the notion monotonic time be incrementing? If
>>>we're not incrementing jiffies, then uptime isn't being incremented, so
>>>to me it doesn't follow that the monotonic time should be incrementing
>>>as well. 
>>
>>Uh, not moving jiffies?  What does this say about any timers that may be 
>>pending?  Say for cron or some such?  Like I said, I picked up this thread a bit 
>>late, but, seems to me that if time is passing, it should pass on both the 
>>jiffies AND the wall clocks.
> 
> 
> My understanding is that we are suspending the box (ie: putting your
> laptop to sleep/hybernate), so for all practical purposes the box is off
> waiting until it is woken up. During that time I don't believe we
> receive timer interrupts. When we are woken up, we should update the
> system time and continue, but as the box wasn't running during the
> interim we shouldn't be increasing the notion of monotonic time. 
> 
> 
>>>It may very well be a POSIX timers spec issue, but it just strikes me as
>>>odd.
>>
>>The spec thing would relate to any sleeps or timers that are pending.  The spec 
>>would seem to say they should complete somewhere near the requested wall time, 
>>but NEVER before.  By not moving jiffies, I think they will be a bit late.  Now, 
>>if they were to complete during the sleep, well those should fire at completion 
>>of the sleep.  If the are to complete after the sleep, then, it seems to me, 
>>they should fire at the requested time.
> 
> 
> Hmmm. That last sentence gives me pause. I guess it comes down to how
> you request your timer expiration: in wall time or system time.  I
> always thought it was in system time, but you know this stuff better
> then I, so I'll defer.

The request can be on the wall clock or on clock_monotonic.  Still, we went 
round and round about how a tick on one should be a tick on the other.  My 
understanding is that the pm_timer was put in the ACPIC to handle this, but then 
I don't know how far down power is going, nor for how long.  I would think at 
some point the discontinuity would be large enough that one would want some user 
service to run and "fix" all the broken time assumptions.  Some sort of a soft 
reboot that would kick the ntp code, cron and so on, much as is done at boot.


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

ps, long week end, out till Tuesday...

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> The request can be on the wall clock or on clock_monotonic.  Still, we went 
> round and round about how a tick on one should be a tick on the other.  My 
> understanding is that the pm_timer was put in the ACPIC to handle this, but 
> then I don't know how far down power is going, nor for how long.  I would 
> think at some point the discontinuity would be large enough that one would 
> want some user service to run and "fix" all the broken time assumptions.  
> Some sort of a soft reboot that would kick the ntp code, cron and so on, 
> much as is done at boot.

Well, it is well possible that discontinuity is days (it usually is 8
hours for me -- I suspend-to-disk before going to sleep), and nothing
prevents you from suspending machine for half a year.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
>>The request can be on the wall clock or on clock_monotonic.  Still, we went 
>>round and round about how a tick on one should be a tick on the other.  My 
>>understanding is that the pm_timer was put in the ACPIC to handle this, but 
>>then I don't know how far down power is going, nor for how long.  I would 
>>think at some point the discontinuity would be large enough that one would 
>>want some user service to run and "fix" all the broken time assumptions.  
>>Some sort of a soft reboot that would kick the ntp code, cron and so on, 
>>much as is done at boot.
> 
> 
> Well, it is well possible that discontinuity is days (it usually is 8
> hours for me -- I suspend-to-disk before going to sleep), and nothing
> prevents you from suspending machine for half a year.
> 

Ok, but then is there some sort of house cleaning that happens to clean up the 
mess?  I am thinking something like the run level change where scripts might run 
to "fix" things.

Now it could be that my ignorance is showing here, possibly this is all being 
done already...

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [pm] fix time after suspend-to-*

[Patrick Mochel]

> Ok, but then is there some sort of house cleaning that happens to clean up the 
> mess?  I am thinking something like the run level change where scripts might run 
> to "fix" things.
> 
> Now it could be that my ignorance is showing here, possibly this is all being 
> done already...

No, it's not. But, it should. 

Userspace behavior on suspend transitions is still a bit fuzzy at best. I 
am beginning to look at userspace requirements, so if anyone wants to send 
me suggestions, no matter how trivial or wacky, please feel free (on- or 
off-list). 

Thanks,


	Pat

Re: [pm] fix time after suspend-to-*

[Nigel Cunningham]

There is a suspend script that has been developed for the 2.4 version.
It should be pretty easy to adapt it for the 2.6 versions. Available at
www.sourceforge.net/projects/swsusp.

Regards,

Nigel

On Tue, 2003-10-28 at 12:43, Patrick Mochel wrote:
> > Ok, but then is there some sort of house cleaning that happens to clean up the 
> > mess?  I am thinking something like the run level change where scripts might run 
> > to "fix" things.
> > 
> > Now it could be that my ignorance is showing here, possibly this is all being 
> > done already...
> 
> No, it's not. But, it should. 
> 
> Userspace behavior on suspend transitions is still a bit fuzzy at best. I 
> am beginning to look at userspace requirements, so if anyone wants to send 
> me suggestions, no matter how trivial or wacky, please feel free (on- or 
> off-list). 
> 
> Thanks,
> 
> 
> 	Pat
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

Re: [pm] fix time after suspend-to-*

[Felipe Alfaro Solana]

On Tue, 2003-10-28 at 00:43, Patrick Mochel wrote:

> Userspace behavior on suspend transitions is still a bit fuzzy at best. I 
> am beginning to look at userspace requirements, so if anyone wants to send 
> me suggestions, no matter how trivial or wacky, please feel free (on- or 
> off-list). 

Many userspace applications are not prepared for suspension, like
Evolution. When suspending the machine for a long time, all IMAP
sessions are broken as their counterpart TCP sockets timeout. While
resuming, Evolution is unable to handle this condition and simply
informs the network connection has been dropped.

What about sending the SIGPWR signal to all userspace processes before
suspending so applications like Evolution can be improved to handle this
signal, drop their IMAP connections and then, when resuming, reestablish
them?

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > Userspace behavior on suspend transitions is still a bit fuzzy at best. I 
> > am beginning to look at userspace requirements, so if anyone wants to send 
> > me suggestions, no matter how trivial or wacky, please feel free (on- or 
> > off-list). 
> 
> Many userspace applications are not prepared for suspension, like
> Evolution. When suspending the machine for a long time, all IMAP
> sessions are broken as their counterpart TCP sockets timeout. While
> resuming, Evolution is unable to handle this condition and simply
> informs the network connection has been dropped.
> 
> What about sending the SIGPWR signal to all userspace processes before
> suspending so applications like Evolution can be improved to handle this
> signal, drop their IMAP connections and then, when resuming, reestablish
> them?

Not sure... We do not want applications to know. Certainly we can't
send a signal; SIGPWR already has some meaning and it would be bad to
override it.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Stephen Rothwell]

On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek <pavel@suse.cz> wrote:
>
> Not sure... We do not want applications to know. Certainly we can't
> send a signal; SIGPWR already has some meaning and it would be bad to
> override it.

And SIGPWR is a bad choice anyway as the default action for SIGPWR
is to terminate the process - I can't see people being amused if all
their processes are killed when they suspend their laptop :-)

We could invent a new signal whose default action is ignore ... Solaris
has SIGFREEZE and SIGTHAW (the comment in the header file says used by CPR
- whatever that is).  SIGSUSPEND and SIGRESUME?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > Not sure... We do not want applications to know. Certainly we can't
> > send a signal; SIGPWR already has some meaning and it would be bad to
> > override it.
> 
> And SIGPWR is a bad choice anyway as the default action for SIGPWR
> is to terminate the process - I can't see people being amused if all
> their processes are killed when they suspend their laptop :-)
> 
> We could invent a new signal whose default action is ignore ... Solaris
> has SIGFREEZE and SIGTHAW (the comment in the header file says used by CPR
> - whatever that is).  SIGSUSPEND and SIGRESUME?

Is adding signal really that easy? I thought there's limited number of
them...

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Stephen Rothwell]

On Tue, 28 Oct 2003 13:29:07 +0100 Pavel Machek <pavel@suse.cz> wrote:
>
> Is adding signal really that easy? I thought there's limited number of
> them...

64.  However, we would need to coordinate with the libc folks ...
and it may not be actually possible if people are using hard coded
signals at the start of the real time range ...

So probably much more pain than its worth.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: [pm] fix time after suspend-to-*

[Peter Chubb]

>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:

Stephen> On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek
Stephen> <pavel@suse.cz> wrote:
Stephen> We could invent a new signal whose default action is ignore
Stephen> ... Solaris has SIGFREEZE and SIGTHAW (the comment in the
Stephen> header file says used by CPR - whatever that is).  SIGSUSPEND
Stephen> and SIGRESUME?

CPR -- checkpoint/restart

POSIX said to use SIGCKPT and SIGCONT (in at least *one* of the draft
1003.1m standards -- I've lost access to them recently, and the
working group stopped working back in 2000)

Suspend/resume is essentially a system-wide checkpoint+restart.

Maybe use SIGCKPT and SIGCONT?  Or even SIGSTOP and SIGCONT (after
all, you're stopping the process, then restarting it)

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.

Re: [pm] fix time after suspend-to-*

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Wed, 29 Oct 2003 09:23:50 +1100, Peter Chubb said:

> Maybe use SIGCKPT and SIGCONT?  Or even SIGSTOP and SIGCONT (after
> all, you're stopping the process, then restarting it)

Some programs do special handling of SIGSTOP (for instance, 'vi' will
drop the terminal out of raw mode) that may not be appropriate for
suspending the system.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> Stephen> On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek
> Stephen> <pavel@suse.cz> wrote:
> Stephen> We could invent a new signal whose default action is ignore
> Stephen> ... Solaris has SIGFREEZE and SIGTHAW (the comment in the
> Stephen> header file says used by CPR - whatever that is).  SIGSUSPEND
> Stephen> and SIGRESUME?
> 
> CPR -- checkpoint/restart
> 
> POSIX said to use SIGCKPT and SIGCONT (in at least *one* of the draft
> 1003.1m standards -- I've lost access to them recently, and the
> working group stopped working back in 2000)
> 
> Suspend/resume is essentially a system-wide checkpoint+restart.
> 
> Maybe use SIGCKPT and SIGCONT?  Or even SIGSTOP and SIGCONT (after
> all, you're stopping the process, then restarting it)

SIGSTOP/SIGCONT is non-starter; too many apps have problem with that.

I guess Patrick's /sbin/hotplug solution is best; implement it as
kill -SIGSTOP -1 if you want to.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Felipe Alfaro Solana]

On Tue, 2003-10-28 at 10:32, Pavel Machek wrote:

> > Many userspace applications are not prepared for suspension, like
> > Evolution. When suspending the machine for a long time, all IMAP
> > sessions are broken as their counterpart TCP sockets timeout. While
> > resuming, Evolution is unable to handle this condition and simply
> > informs the network connection has been dropped.
> > 
> > What about sending the SIGPWR signal to all userspace processes before
> > suspending so applications like Evolution can be improved to handle this
> > signal, drop their IMAP connections and then, when resuming, reestablish
> > them?
> 
> Not sure... We do not want applications to know. Certainly we can't
> send a signal; SIGPWR already has some meaning and it would be bad to
> override it.

OK, maybe using SIGPWR is not a good idea, but some userspace
applications need to know when the system is going to sleep. Even more,
userspace apps should be able to tell the kernel whether suspending the
system at a given moment is a good idea or not.

Examples:

1. Network connections must be reestablished. A userspace program can't
try to automatically reestablish a broken TCP connection for no apparent
reason. A broken TCP connection could be the cause of an overloaded or
broken server/service. If we do not inform userspace processes that the
system is going to sleep (or that the system has been brought up from
standby), they will blindly try to restore TCP connections back, even
when the remote server is broken, generating a lot of unnecesary
traffic.

2. Sound: I've been unable to suspend via APM with the Yamaha YMFPCI
driver loaded. I need to unload it, but I can't unload it if there is
some app using the sound driver. Before going to sleep, sound-aware apps
could be informed that the system is being put to sleep so that they
stop playing sound gracefully. Thus, the sound driver could be unloaded.

3. CD/DVD burners: Some userspace apps should be able to try to avoid
suspending the system. Imagine what could happen if average joe user
tries to suspend while burning a CD. The CD recording app should be able
to notify the kernel that a real-time sensitive operation is being taken
place. A policy-based decision system could take the responsibility to
prevent the system from entering suspension or ignore the userspace
application and force the suspend, for example, to prevent losing data
when a laptop is really, really low on batteries.

Don't know if I'm able to convince you ;-)

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > Not sure... We do not want applications to know. Certainly we can't
> > send a signal; SIGPWR already has some meaning and it would be bad to
> > override it.
> 
> OK, maybe using SIGPWR is not a good idea, but some userspace
> applications need to know when the system is going to sleep. Even more,
> userspace apps should be able to tell the kernel whether suspending the
> system at a given moment is a good idea or not.

You are not asking userspace whether to reboot or not, and you should
not ask them about suspend, either.

> Examples:
> 
> 1. Network connections must be reestablished. A userspace program can't
> try to automatically reestablish a broken TCP connection for no apparent
> reason. A broken TCP connection could be the cause of an overloaded or
> broken server/service. If we do not inform userspace processes that the
> system is going to sleep (or that the system has been brought up from
> standby), they will blindly try to restore TCP connections back, even
> when the remote server is broken, generating a lot of unnecesary
> traffic.

gettimeofday(), if I slept for too long, oops, something strange
happened (maybe there was heavy io load and I was swapped out? or
suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.

> 2. Sound: I've been unable to suspend via APM with the Yamaha YMFPCI
> driver loaded. I need to unload it, but I can't unload it if there is
> some app using the sound driver. Before going to sleep, sound-aware apps
> could be informed that the system is being put to sleep so that they
> stop playing sound gracefully. Thus, the sound driver could be
> unloaded.

Fix the driver.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Felipe Alfaro Solana]

On Tue, 2003-10-28 at 18:28, Pavel Machek wrote:

> You are not asking userspace whether to reboot or not, and you should
> not ask them about suspend, either.

OK, so how should the system behave when a real-time-like process is
running? I talked about the CD burning example. Should the kernel simply
ignore the process and suspend?

> > 1. Network connections must be reestablished. A userspace program can't
> > try to automatically reestablish a broken TCP connection for no apparent
> > reason. A broken TCP connection could be the cause of an overloaded or
> > broken server/service. If we do not inform userspace processes that the
> > system is going to sleep (or that the system has been brought up from
> > standby), they will blindly try to restore TCP connections back, even
> > when the remote server is broken, generating a lot of unnecesary
> > traffic.
> 
> gettimeofday(), if I slept for too long, oops, something strange
> happened (maybe there was heavy io load and I was swapped out? or
> suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.

Does "gettimeofday()" have into account the effect of adjusting the time
twice a year, once to make time roll forward one hour and another one to
roll it back?

Re: [pm] fix time after suspend-to-*

[Andreas Schwab]

Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> writes:

> Does "gettimeofday()" have into account the effect of adjusting the time
> twice a year, once to make time roll forward one hour and another one to
> roll it back?

There's no such thing in UTC.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [pm] fix time after suspend-to-*

[George Anzinger]

Felipe Alfaro Solana wrote:
> On Tue, 2003-10-28 at 18:28, Pavel Machek wrote:
> 
> 
>>You are not asking userspace whether to reboot or not, and you should
>>not ask them about suspend, either.
> 
> 
> OK, so how should the system behave when a real-time-like process is
> running? I talked about the CD burning example. Should the kernel simply
> ignore the process and suspend?
> 
> 
>>>1. Network connections must be reestablished. A userspace program can't
>>>try to automatically reestablish a broken TCP connection for no apparent
>>>reason. A broken TCP connection could be the cause of an overloaded or
>>>broken server/service. If we do not inform userspace processes that the
>>>system is going to sleep (or that the system has been brought up from
>>>standby), they will blindly try to restore TCP connections back, even
>>>when the remote server is broken, generating a lot of unnecesary
>>>traffic.
>>
>>gettimeofday(), if I slept for too long, oops, something strange
>>happened (maybe there was heavy io load and I was swapped out? or
>>suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.
> 
> 
> Does "gettimeofday()" have into account the effect of adjusting the time
> twice a year, once to make time roll forward one hour and another one to
> roll it back?

Actually gettimeofday() does NOT do that.  It always returns GMT since 1970. 
The daylight savings thing is really a timezone shift, not a time shift.

My suggestion, which I admit may rely on a particular distro, is to define two 
new run levels.  One for going to sleep and one to wake up.  This is how the 
system boots and powers down already.  The new levels would allow applications 
which have special needs to put the proper notifier stuff in the runlevel 
directory, just as is done for boot/ shutdown.  It is this code which should 
tell the system to sleep, just as the shutdown run level shuts off the machine.
> 
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > You are not asking userspace whether to reboot or not, and you should
> > not ask them about suspend, either.
> 
> OK, so how should the system behave when a real-time-like process is
> running? I talked about the CD burning example. Should the kernel simply
> ignore the process and suspend?

Yes.

> > > 1. Network connections must be reestablished. A userspace program can't
> > > try to automatically reestablish a broken TCP connection for no apparent
> > > reason. A broken TCP connection could be the cause of an overloaded or
> > > broken server/service. If we do not inform userspace processes that the
> > > system is going to sleep (or that the system has been brought up from
> > > standby), they will blindly try to restore TCP connections back, even
> > > when the remote server is broken, generating a lot of unnecesary
> > > traffic.
> > 
> > gettimeofday(), if I slept for too long, oops, something strange
> > happened (maybe there was heavy io load and I was swapped out? or
> > suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.
> 
> Does "gettimeofday()" have into account the effect of adjusting the time
> twice a year, once to make time roll forward one hour and another one to
> roll it back?

Not sure how it is supposed to work, but here I just have ntpd
step-setting by one hour...
							Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Gabriel Paubert]

On Wed, Oct 29, 2003 at 10:38:03AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > You are not asking userspace whether to reboot or not, and you should
> > > not ask them about suspend, either.
> > 
> > OK, so how should the system behave when a real-time-like process is
> > running? I talked about the CD burning example. Should the kernel simply
> > ignore the process and suspend?
> 
> Yes.
> 
> > > > 1. Network connections must be reestablished. A userspace program can't
> > > > try to automatically reestablish a broken TCP connection for no apparent
> > > > reason. A broken TCP connection could be the cause of an overloaded or
> > > > broken server/service. If we do not inform userspace processes that the
> > > > system is going to sleep (or that the system has been brought up from
> > > > standby), they will blindly try to restore TCP connections back, even
> > > > when the remote server is broken, generating a lot of unnecesary
> > > > traffic.
> > > 
> > > gettimeofday(), if I slept for too long, oops, something strange
> > > happened (maybe there was heavy io load and I was swapped out? or
> > > suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.
> > 
> > Does "gettimeofday()" have into account the effect of adjusting the time
> > twice a year, once to make time roll forward one hour and another one to
> > roll it back?
> 
> Not sure how it is supposed to work, but here I just have ntpd
> step-setting by one hour...

Well, gettimeofday() is supposed to return UT. It does not care at all
about local time, which would be a 100% userspace problem if it were
not for broken filesystems which store timestamps in local time.

Going off-topic: on a typical distribution the files used for UT to 
localtime conversion are in/usr/share/zoneinfo. Also ntp exclusively
transmits UT, and is certainly not responsible for these hour steps.

	Gabriel.

PCI Bus error 6290 or 0290

[Remus]

Hi folks,

I have installed the latest 2.6.0-test9 kernel and I get this error
messages:
Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 6290.
Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 0290.

The problem is with Realtek (RTL-8139) network card drivers.

root@fw:~# lspci -v
00:05.0 Host bridge: Silicon Integrated Systems [SiS] 85C496 (rev 31)
        Flags: bus master, medium devsel, latency 0

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Edimax Computer Co.: Unknown device 9503
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at fc00 [size=256]
        Memory at ffbeff00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2

00:0f.0 Ethernet controller: Compex ReadyLink 2000 (rev 0a)
        Flags: medium devsel, IRQ 7
        I/O ports at ff80 [size=32]
        Expansion ROM at ffbe0000 [disabled] [size=32K]

Any ideas/solutions?

Thanks in advance

Remus

Re: PCI Bus error 6290 or 0290

[Meelis Roos]

R> I have installed the latest 2.6.0-test9 kernel and I get this error
R> messages:
R> Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 6290.
R> Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 0290.
R> 
R> The problem is with Realtek (RTL-8139) network card drivers.
[...]
R> Any ideas/solutions?

I had the same problem on a K6-2 with some Asus MB. Both Realtek 8139
and tulip (21140) refused to work in a PCI slot. Realtek gave these
messages, tulip told that send timed out. A quick workaround was to put
the NIC into another PCI slot. I don't know the real reason and I don't
have the specific computer available for additional tests any more.

-- 
Meelis Roos (mroos@linux.ee)

Re: PCI Bus error 6290 or 0290

[Remus]

I tried all PCI slots, but still shows the same errors.

Remus

----- Original Message ----- 
From: "Meelis Roos" <mroos@linux.ee>
To: <rmocius@auste.elnet.lt>; <linux-kernel@vger.kernel.org>
Sent: Wednesday, October 29, 2003 12:40 PM
Subject: Re: PCI Bus error 6290 or 0290


> R> I have installed the latest 2.6.0-test9 kernel and I get this error
> R> messages:
> R> Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 6290.
> R> Oct 29 13:51:39 fw kernel: eth1: PCI Bus error 0290.
> R>
> R> The problem is with Realtek (RTL-8139) network card drivers.
> [...]
> R> Any ideas/solutions?
>
> I had the same problem on a K6-2 with some Asus MB. Both Realtek 8139
> and tulip (21140) refused to work in a PCI slot. Realtek gave these
> messages, tulip told that send timed out. A quick workaround was to put
> the NIC into another PCI slot. I don't know the real reason and I don't
> have the specific computer available for additional tests any more.
>
> -- 
> Meelis Roos (mroos@linux.ee)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [pm] fix time after suspend-to-*

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
>>>You are not asking userspace whether to reboot or not, and you should
>>>not ask them about suspend, either.
>>
>>OK, so how should the system behave when a real-time-like process is
>>running? I talked about the CD burning example. Should the kernel simply
>>ignore the process and suspend?
> 
> 
> Yes.
> 
> 
>>>>1. Network connections must be reestablished. A userspace program can't
>>>>try to automatically reestablish a broken TCP connection for no apparent
>>>>reason. A broken TCP connection could be the cause of an overloaded or
>>>>broken server/service. If we do not inform userspace processes that the
>>>>system is going to sleep (or that the system has been brought up from
>>>>standby), they will blindly try to restore TCP connections back, even
>>>>when the remote server is broken, generating a lot of unnecesary
>>>>traffic.
>>>
>>>gettimeofday(), if I slept for too long, oops, something strange
>>>happened (maybe there was heavy io load and I was swapped out? or
>>>suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.
>>
>>Does "gettimeofday()" have into account the effect of adjusting the time
>>twice a year, once to make time roll forward one hour and another one to
>>roll it back?
> 
> 
> Not sure how it is supposed to work, but here I just have ntpd
> step-setting by one hour...

It is really a time zone change....

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> >Not sure how it is supposed to work, but here I just have ntpd
> >step-setting by one hour...
> 
> It is really a time zone change....

I though so, but it does not work like that here.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Tue, 28 Oct 2003 10:32:33 +0100, Pavel Machek said:

> Not sure... We do not want applications to know. Certainly we can't
> send a signal; SIGPWR already has some meaning and it would be bad to
> override it.

You are correct that SIGPWR already has an assigned semantic.

However, I'm not convinced that we don't want applications to know.
Others have mentioned timeouts of network connections, and there's other
issues as well - for instance, on my laptop, it is almost guaranteed (due to my
work habits) that if I were to suspend it, when it wakes up the network
configuration would be *wrong*.  It's possible to intuit what the right
config is by looking at the number of ethernets and their link state, but
that requires a wakeup of *something* in userspace - blindly going on
as if nothing happened simply won't work.

Would having a pair of 'sleep/wakeup' calls in /etc/inittab (similar to the
powerfail/powerok pair) be a solution here?  

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > Not sure... We do not want applications to know. Certainly we can't
> > send a signal; SIGPWR already has some meaning and it would be bad to
> > override it.
> 
> You are correct that SIGPWR already has an assigned semantic.
> 
> However, I'm not convinced that we don't want applications to know.
> Others have mentioned timeouts of network connections, and there's other
> issues as well - for instance, on my laptop, it is almost guaranteed (due to my
> work habits) that if I were to suspend it, when it wakes up the network
> configuration would be *wrong*.  It's possible to intuit what the right
> config is by looking at the number of ethernets and their link state, but
> that requires a wakeup of *something* in userspace - blindly going on
> as if nothing happened simply won't work.
> 
> Would having a pair of 'sleep/wakeup' calls in /etc/inittab (similar to the
> powerfail/powerok pair) be a solution here?  

Patrick has a patch to send event down using "hotplug" system.

									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Patrick Mochel]

> Many userspace applications are not prepared for suspension, like
> Evolution. When suspending the machine for a long time, all IMAP
> sessions are broken as their counterpart TCP sockets timeout. While
> resuming, Evolution is unable to handle this condition and simply
> informs the network connection has been dropped.
> 
> What about sending the SIGPWR signal to all userspace processes before
> suspending so applications like Evolution can be improved to handle this
> signal, drop their IMAP connections and then, when resuming, reestablish
> them?

SIGPWR already has meaning, and I do not want to overload it. Besides a
signal does not seem like the best solution - a new signal will require
each application to be recompiled, and may cause some unexpected behavior
as some otherwise stable applications break. I.e. it's too intrusive of a
requirement. Plus AFAIK, signals are delivered asynchronously, so there is
no way to know if the applications finished doing the necessary work..
                                                                                
I posted the patch below to the linux-acpi list a few weeks ago. It causes
/sbin/hotplug to be called on both suspend and resume. It's a lightweight,
non-intrusive notification mechanism that allows only the applications
that care about the events be notified of the transition.
                                                                                
It waits for the call to return, which guarantees that the applications
will have enough time to complete what ever it is they need to do (close
IMAP connections, shut down the 3d accelerator, etc).
                                                                                
AFAIK, /sbin/hotplug now also generates a D-BUS message, which the desktop
applications will receive, allowing them to transparently hook into the
sequence.


	Pat

===== kernel/power/main.c 1.16 vs edited =====
--- 1.16/kernel/power/main.c	Mon Sep  8 15:13:46 2003
+++ edited/kernel/power/main.c	Tue Sep 30 15:35:47 2003
@@ -16,6 +16,7 @@
 #include <linux/delay.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/kmod.h>
 #include <linux/pm.h>
 
 
@@ -117,6 +118,59 @@
 
 
 
+#ifdef CONFIG_HOTPLUG
+
+
+/**
+ *	user_suspend - notify userspace of suspend.
+ *
+ *	Notify userspace that we're going to sleep, and wait for it to finish
+ *	shutting down whatever it needs before we proceed.
+ *
+ */
+	
+static int tell_userspace(char * state, int suspend)
+{
+	char * argv[3];
+	char * envp[5];
+	char env_action[16];
+	char env_state[16];
+	int error;
+
+	if (!hotplug_path[0])
+		return 0;
+
+	argv[0] = hotplug_path;
+	argv[1] = "power";
+	argv[2] = NULL;
+
+	snprintf(env_state,16,"STATE=%s",state);
+	snprintf(env_action,16,"ACTION=%s",suspend ? "suspend" : "resume");
+
+	envp[0] = "HOME=/";
+	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+	envp[2] = env_action;
+	envp[3] = env_state;
+	envp[4] = NULL;
+
+	pr_debug("PM: Calling userspace: %s %s\n",env_action,env_state);
+
+	error = call_usermodehelper(argv[0],argv,envp,1);
+
+	return error;
+}
+
+
+#else /* CONFIG_HOTPLUG */
+
+
+static int tell_userspace(char * state, int suspend)
+{
+	return 0;
+}
+
+#endif 
+
 
 char * pm_states[] = {
 	[PM_SUSPEND_STANDBY]	= "standby",
@@ -150,9 +204,12 @@
 		goto Unlock;
 	}
 
+	if ((error = tell_userspace(pm_states[state],1)))
+		goto Unlock;
+
 	if (state == PM_SUSPEND_DISK) {
 		error = pm_suspend_disk();
-		goto Unlock;
+		goto Resume;
 	}
 
 	pr_debug("PM: Preparing system for suspend\n");
@@ -164,6 +221,8 @@
 
 	pr_debug("PM: Finishing up.\n");
 	suspend_finish(state);
+ Resume:
+	tell_userspace(pm_states[state],0);
  Unlock:
 	up(&pm_sem);
 	return error;

Re: [pm] fix time after suspend-to-*

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Tue, 28 Oct 2003 10:20:08 PST, Patrick Mochel said:

> I posted the patch below to the linux-acpi list a few weeks ago. It causes
> /sbin/hotplug to be called on both suspend and resume. It's a lightweight,
> non-intrusive notification mechanism that allows only the applications
> that care about the events be notified of the transition.

Untested yet, but it appears to be sufficient for what my config needs. Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [pm] fix time after suspend-to-*

[Felipe Alfaro Solana]

On Tue, 2003-10-28 at 19:20, Patrick Mochel wrote:

> I posted the patch below to the linux-acpi list a few weeks ago. It causes
> /sbin/hotplug to be called on both suspend and resume. It's a lightweight,
> non-intrusive notification mechanism that allows only the applications
> that care about the events be notified of the transition.

I really like it. Will starting playing with it.

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> > Uh, not moving jiffies?  What does this say about any timers that may be 
> > pending?  Say for cron or some such?  Like I said, I picked up this thread a bit 
> > late, but, seems to me that if time is passing, it should pass on both the 
> > jiffies AND the wall clocks.
> 
> My understanding is that we are suspending the box (ie: putting your
> laptop to sleep/hybernate), so for all practical purposes the box is off
> waiting until it is woken up. During that time I don't believe we
> receive timer interrupts. When we are woken up, we should update the
> system time and continue, but as the box wasn't running during the
> interim we shouldn't be increasing the notion of monotonic time. 

No timer interrupts, definitely. Machine is powered off.

> Pavel: You new patch looks ok wrt the locking issue. I'm still pretty
> suspicious of the clock_cmos_diff but I'll trust you that it does the
> right thing (this has been tested, right? :)

It worked in apm, it should work now, and yes I did some tests.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Pavel Machek]

Hi!

> >>Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally
> >>you need to have the xtime_lock to safely manipulate xtime. Also,
> >>couldn't you just call settimeofday() instead?  The bit about manually
> >>setting the timezone also confuses me, as we don't normally do this at
> >>bootup in the kernel.  
> >>
> >
> >
> >I took it straight from apm.c... But it is well possible that it needs
> >some locking. OTOH this runs with interrupts disabled, perhaps
> >thats enough?
> 
> I lost (never saw) the first of this thread, BUT, if this is 2.6, I 
> strongly recommend that settimeofday() NOT be called.  It will try to 
> adjust wall_to_motonoic, but, as this appears to be a correction for time 
> lost while sleeping, wall_to_monotonic should not change.
> 
> As to locking, ints off for UP, but you need the full lock for SMP systems.

Okay, suspend is currently not supported on SMP, but we should play it
safe. What about this one? [Compile tested only, have to get some sleep.]

								Pavel

--- clean/arch/i386/kernel/time.c	2003-10-09 00:13:14.000000000 +0200
+++ linux/arch/i386/kernel/time.c	2003-10-24 01:38:04.000000000 +0200
@@ -271,16 +271,37 @@
 	unsigned long retval;
 
 	spin_lock(&rtc_lock);
-
 	retval = mach_get_cmos_time();
-
 	spin_unlock(&rtc_lock);
 
 	return retval;
 }
 
+static long clock_cmos_diff;
+
+static int pit_suspend(struct sys_device *dev, u32 state)
+{
+	/*
+	 * Estimate time zone so that set_time can update the clock
+	 */
+	clock_cmos_diff = -get_cmos_time();
+	clock_cmos_diff += get_seconds();
+	return 0;
+}
+
+static int pit_resume(struct sys_device *dev)
+{
+	write_seqlock_irq(&xtime_lock);
+	xtime.tv_sec = get_cmos_time() + clock_cmos_diff;
+	xtime.tv_nsec = 0; 
+	write_sequnlock_irq(&xtime_lock);
+	return 0;
+}
+
 static struct sysdev_class pit_sysclass = {
 	set_kset_name("pit"),
+	.resume = pit_resume,
+	.suspend = pit_suspend,
 };
 
 /* XXX this driverfs stuff should probably go elsewhere later -john */


-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [pm] fix time after suspend-to-*

[Patrick Mochel]

> Okay, suspend is currently not supported on SMP, but we should play it
> safe. What about this one? [Compile tested only, have to get some sleep.]

Applied, thanks.


	Pat

Re: [pm] fix time after suspend-to-*

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> @@ -271,16 +271,39 @@
>  	unsigned long retval;
>  
>  	spin_lock(&rtc_lock);
> -
>  	retval = mach_get_cmos_time();
> -
>  	spin_unlock(&rtc_lock);
>  
>  	return retval;

I just love these subtle little fixes.  They can really make a
difference.

-- 
Måns Rullgård
mru@kth.se

Re: [pm] fix time after suspend-to-*

[Mathias Fröhlich]

> > Userspace behavior on suspend transitions is still a bit fuzzy at best. I
> > am beginning to look at userspace requirements, so if anyone wants to send
> > me suggestions, no matter how trivial or wacky, please feel free (on- or
> > off-list).
> 
> Many userspace applications are not prepared for suspension, like
> Evolution. When suspending the machine for a long time, all IMAP
> sessions are broken as their counterpart TCP sockets timeout. While
> resuming, Evolution is unable to handle this condition and simply
> informs the network connection has been dropped.
>
> What about sending the SIGPWR signal to all userspace processes before
> suspending so applications like Evolution can be improved to handle this
> signal, drop their IMAP connections and then, when resuming, reestablish
> them?

I think that messagebus is for such stuff. ?!

   Greetings

      Mathias

-- 
Mathias Fröhlich, email: Mathias.Froehlich@web.de