fix time after suspend-to-*
Subsystems (2)
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].
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +25 -2
@@ -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 */
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 5 lines · Pavel Machek
Hi!
This adds suspend/resume methods for time, so that real time is refreshed from cmos when suspend is finished. Please apply,
[snip]
Quoted 19 lines
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +18
-0+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;
arch/i386/kernel/time.c line 307
Quoted 10 lines
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +7
-0+ 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
Hi!
Quoted 9 lines
Quoted 9 lines
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +9
-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 ; +} +
...
Quoted 6 lines
Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally you need to have the
xtime_lockto safely manipulate xtime. Also, couldn't you just callsettimeofday()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
Signature · 2 lines
Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Quoted 23 lines · Pavel Machek
Hi!
Quoted 9 lines
Quoted 9 lines
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +9
-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 ; +} +...
Quoted 6 lines
Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally you need to have the
xtime_lockto safely manipulate xtime. Also, couldn't you just callsettimeofday()instead? The bit about manually setting the timezone also confuses me, as we don't normally do this at bootup in the kernel.
Quoted 3 lines
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.
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Quoted 4 lines · George Anzinger
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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
Quoted 10 lines · john stultz
Quoted 1 line · George Anzinger
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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.
Quoted 3 lines
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.
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Hi!
Quoted 19 lines
Quoted 10 lines
Quoted 4 lines
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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.
Quoted 3 lines
It may very well be a POSIX timers spec issue, but it just strikes me as odd.
Quoted 6 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 12 lines · George Anzinger
Quoted 10 lines · john stultz
Quoted 4 lines · George Anzinger
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 2 lines
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
Quoted 3 lines · john stultz
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
Quoted 27 lines · john stultz
Quoted 4 lines · George Anzinger
Quoted 2 lines · john stultz
On Thu, 2003-10-23 at 13:23, George Anzinger wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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.
Quoted 3 lines
Quoted 2 lines
It may very well be a POSIX timers spec issue, but it just strikes me as odd.
Quoted 7 lines
Quoted 1 line
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.
Signature · 5 lines
George Anzinger [email protected] 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...
Hi!
Quoted 8 lines
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 thepm_timerwas 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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 10 lines · Pavel Machek
Hi!
Quoted 1 line
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 thepm_timerwas 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...
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Quoted 7 lines
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
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
Quoted 24 lines · Patrick Mochel
Quoted 6 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 5 lines
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.
Quoted 4 lines · Patrick Mochel
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?
Hi!
Quoted 11 lines
Quoted 4 lines
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.
Quoted 4 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 4 lines · On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek <[email protected]> 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?
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Hi!
Quoted 11 lines
Quoted 3 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 3 lines · On Tue, 28 Oct 2003 13:29:07 +0100 Pavel Machek <[email protected]> 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.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Stephen" == Stephen Rothwell <[email protected]> writes:
Stephen> On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek Stephen> <[email protected]> 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.
Quoted 2 lines · Peter Chubb
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.
Hi!
Quoted 9 lines
Stephen> On Tue, 28 Oct 2003 10:32:33 +0100 Pavel Machek Stephen> <[email protected]> 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
Quoted 8 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 6 lines · Pavel Machek
Quoted 6 lines
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.
Quoted 8 lines
Quoted 4 lines
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 ;-)
Hi!
Quoted 8 lines
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 6 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 2 lines · Pavel Machek
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?
Quoted 9 lines
Quoted 8 lines
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.
Quoted 3 lines
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?
Quoted 3 lines · Felipe Alfaro Solana
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.
Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected] 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."
Quoted 21 lines · Felipe Alfaro Solana
Quoted 2 lines · Pavel Machek
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?
Quoted 9 lines
Quoted 8 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Hi!
Quoted 6 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 3 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 24 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 2 lines
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.
Quoted 13 lines
Quoted 12 lines
Quoted 8 lines
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.
Quoted 6 lines
Quoted 3 lines
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
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 000: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
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.
Signature · 1 line
Meelis Roos ([email protected])
Re: PCI Bus error 6290 or 0290
I tried all PCI slots, but still shows the same errors.
Remus
----- Original Message -----
From: "Meelis Roos" <[email protected]>
To: <[email protected]>; <[email protected]>
Sent: Wednesday, October 29, 2003 12:40 PM
Subject: Re: PCI Bus error 6290 or 0290
Quoted 23 lines
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.
Signature · 6 lines
Meelis Roos ([email protected]) - 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/
Quoted 27 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 2 lines
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.
Quoted 13 lines
Quoted 12 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 3 lines
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....
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Hi!
Quoted 4 lines
Quoted 2 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 3 lines · Pavel Machek
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?
Hi!
Quoted 15 lines
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 11 lines
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 =====
kernel/power/main.c +60 -1
@@ -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;
Quoted 4 lines · Patrick Mochel
I posted the patch below to the linux-acpi list a few weeks ago. It causes
/sbin/hotplugto 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.
Quoted 4 lines · Patrick Mochel
I posted the patch below to the linux-acpi list a few weeks ago. It causes
/sbin/hotplugto 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.
Hi!
Quoted 11 lines
Quoted 4 lines
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.
Quoted 3 lines
Pavel: You new patch looks ok wrt the locking issue. I'm still pretty suspicious of the
clock_cmos_diffbut 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
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Hi!
Quoted 12 lines
Quoted 11 lines
Quoted 6 lines
Forgive me, I'm not totally familiar w/ the sysfs/pm stuff, but normally you need to have the
xtime_lockto safely manipulate xtime. Also, couldn't you just callsettimeofday()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?
Quoted 6 lines
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 adjustwall_to_motonoic, but, as this appears to be a correction for time lost while sleeping,wall_to_monotonicshould 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
arch/i386/kernel/time.c +23 -2
@@ -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 */
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Patrick Mochel
AppliedQuoted 3 lines
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
arch/i386/kernel/time.c line 277
Quoted 10 lines · Pavel Machek
arch/i386/kernel/time.c renamed from linux/arch/i386/kernel/time.c +0
-2@@ -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.
Signature · 2 lines
Måns Rullgård [email protected]