Software Suspend 2.0 for Linux 2.4 and 2.6 kernels is now available from
http://swsusp.sf.net. The 2.0 release is a major advance over previous
versions and includes the following features:
- Support for HighMem[1], SMP[2] and preemptive kernels.
- Support for any number of swap partitions and/or files.
- Full asynchronous I/O and readahead for synchronous I/O for maximum
throughput.
- Image compression (LZF and GZIP - the former is very fast and highly
recommended).
- Support for saving a full image of your memory, resulting in a fast,
responsive system after resuming.
- Support for plugins: data transformers (compression, encryption) and
new storage backends (NFS support is planned).
- Nice user interface (Bootsplash (http://www.bootsplash.org)
compatible;
- The ability to specify a maximum image size;
- The ability to cancel a suspend by pressing Escape (for security, this
can be disabled).
- Speed and reliability. Software Suspend 2.0 has been extensively
tested in a variety of configurations over many months. It is not
guaranteed to be perfect, but bugs found will be hunted and fixed
quickly.
The Software Suspend website includes extensive documentation, including
known issues (primarily DRI and USB support) and FAQS. A well-used
mailing list is also available.
Known issues with Suspend 2.0 are as follows:
- DRI support is lacking power management support under 2.4 & 2.6.
- AGP support under 2.6 is partially implemented.
- USB support under 2.4 and 2.6 is lacking.
- SMP support is currently 2.4 only.
- Other drivers have varying degrees of power management support.
- There is currently no support for discontig memory.
- Suspend currently requires the PSE extension (check /proc/cpuinfo).
- Highmem >4GB is currently not supported.
- SMP currently suffers from lost interrupts during resuming
- 2.6 does not currently flush caches properly before powering down.
Some of these issues have work-arounds available: check the FAQs for
details.
Note that two patches are required to use suspend: one for the
particular kernel version you are using (make sure you get the most
recent for your kernel version), and a second (applied afterwards)
contains the core files.
Special thanks go to Gabor Kuti, Pavel Machek and Florent Chabaud for
their work, which I have built on; to Michael Frank for many months of
extensive testing of the code, to Marc Lehmann for supplying the LZF
compressor, to Bernard Blackham for maintaining the swsusp.sf.net
website and especially to LinuxFund.org for their sponsorship of the
project, which has allowed me to work full-time on Software Suspend over
the last four months.
Finally, heres a little ditty, to be sung to the tune of the 'The
Pirates Who Don't Do Anything'
(http://www.bassbios.com/bodclan/pirates.mp3)
I'm just a user who wanted to suspend,
I didn't want to be a kernel hacker at all!
I'm just a user who wanted to suspend,
and now I'm happy because I can suspend.
Well I've never been to LinuxConf
and I've never written a device driver
And I've never talked to Linus
and I'm not an expert at BK
And I don't normally get paid to do this
and I don't own any hardware manuals
And I've never been to Boston in the fall...
[1] Up to 4GB.
[2] SMP is currently only supported under 2.4; 2.6 support should not be
far away.
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
Nigel Cunningham <[email protected]> writes:
> Software Suspend 2.0 for Linux 2.4 and 2.6 kernels is now available from
> http://swsusp.sf.net. The 2.0 release is a major advance over previous
> versions and includes the following features:
The patches fail on a 2.6.2-rc2 kernel. Are there any patches for
post-2.6.1 kernels?
--
M?ns Rullg?rd
[email protected]
I hadn't noticed 2.6.2 was out. I'll start preparing a new patch now.
Regards,
Nigel
On Fri, 2004-01-30 at 23:04, M?ns Rullg?rd wrote:
> Nigel Cunningham <[email protected]> writes:
>
> > Software Suspend 2.0 for Linux 2.4 and 2.6 kernels is now available from
> > http://swsusp.sf.net. The 2.0 release is a major advance over previous
> > versions and includes the following features:
>
> The patches fail on a 2.6.2-rc2 kernel. Are there any patches for
> post-2.6.1 kernels?
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
Ah. I see. It's not out, but you want bleeding edge :>
> The patches fail on a 2.6.2-rc2 kernel. Are there any patches for
> post-2.6.1 kernels?
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
Hi.
On Sat, 2004-01-31 at 19:22, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Except that it doesn't seem to work...
> 1. patched in software-suspend-core-2.0-whole -- worked fine
> 2. software-suspend-linux-2.6.1-rev3-whole:
> 2a. can't autodetect files to patch
> 2b. alot of patching fails
>
> Is there something obvious I'm doing wrong? :/
Yes. Apply the patches the other way around - the version specific one
first, then the core. Oh, you'll also want to get the latest 2.6.1 patch
(http://swsusp.sf.net).
Regards,
Nigel
--
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Except that it doesn't seem to work...
1. patched in software-suspend-core-2.0-whole -- worked fine
2. software-suspend-linux-2.6.1-rev3-whole:
2a. can't autodetect files to patch
2b. alot of patching fails
Is there something obvious I'm doing wrong? :/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAG0mXZl/BHdU+lYMRAq80AJ9x3BD5fgtgUtT+CFSYAP4XPTBzBgCglhZW
1hq7ML2PynAmDWCCIRGrJk8=
=xU2/
-----END PGP SIGNATURE-----
Hi.
On Sat, 2004-01-31 at 19:48, Joseph Pingenot wrote:
> Coupla quick questions for you, while we're on the topic.
>
> I get lots of fails against 2.6.2-rc2-mm1; will the -rcX kernels
> be addressed, or will the patches only be against non-rc kernels?
> What about -mm kernels?
In the past I have only done patches against the 2.6.x kernels. I'm
thinking, however, of requesting space on kernel.org for patches against
-rcX and -mm kernels. You're the second person to ask. If I get asked
some more, I might do it :> (It's not that it's hard, just that it takes
time and today is my last day working on the code full time).
> Also, how does this differ from what is currently in the vanilla
> kernels?
The best way to answer that is to point to
http://swsusp.sourceforge.net/features.html.
Regards,
Nigel
--
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.
>From Nigel Cunningham on Saturday, 31 January, 2004:
>Hi.
>On Sat, 2004-01-31 at 19:22, Luke-Jr wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Except that it doesn't seem to work...
>> 1. patched in software-suspend-core-2.0-whole -- worked fine
>> 2. software-suspend-linux-2.6.1-rev3-whole:
>> 2a. can't autodetect files to patch
>> 2b. alot of patching fails
>>
>> Is there something obvious I'm doing wrong? :/
>Yes. Apply the patches the other way around - the version specific one
>first, then the core. Oh, you'll also want to get the latest 2.6.1 patch
>(http://swsusp.sf.net).
Coupla quick questions for you, while we're on the topic.
I get lots of fails against 2.6.2-rc2-mm1; will the -rcX kernels
be addressed, or will the patches only be against non-rc kernels?
What about -mm kernels?
Also, how does this differ from what is currently in the vanilla
kernels?
Thanks!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 31 January 2004 06:37 am, Nigel Cunningham wrote:
> On Sat, 2004-01-31 at 19:22, Luke-Jr wrote:
> > Except that it doesn't seem to work...
> > 1. patched in software-suspend-core-2.0-whole -- worked fine
> > 2. software-suspend-linux-2.6.1-rev3-whole:
> > 2a. can't autodetect files to patch
> > 2b. alot of patching fails
> Yes. Apply the patches the other way around - the version specific one
> first, then the core. Oh, you'll also want to get the latest 2.6.1 patch
> (http://swsusp.sf.net).
What is considered the latest? rev implies that it would be a revision over
the normal 2.6.1 patch...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD4DBQFAG1fKZl/BHdU+lYMRArrVAJ9Vtch17abyMnjidjrTqjR8P1ewZACY/pV4
sbplEZYAERvc5Ej2aDK/fg==
=VoOU
-----END PGP SIGNATURE-----
>From Nigel Cunningham on Saturday, 31 January, 2004:
>Hi.
'ello.
>On Sat, 2004-01-31 at 19:48, Joseph Pingenot wrote:
>> Coupla quick questions for you, while we're on the topic.
>>
>> I get lots of fails against 2.6.2-rc2-mm1; will the -rcX kernels
>> be addressed, or will the patches only be against non-rc kernels?
>> What about -mm kernels?
>
>In the past I have only done patches against the 2.6.x kernels. I'm
>thinking, however, of requesting space on kernel.org for patches against
>-rcX and -mm kernels. You're the second person to ask. If I get asked
That'd rock. It's a very important thing nowadays.
>some more, I might do it :> (It's not that it's hard, just that it takes
Hmm. Do I have to be a *new* person to ask, or can I just keep
asking until you give in? ;)
>time and today is my last day working on the code full time).
Oi! I'll give you five (US) dollars. Is that near enough? :)
Actually, in all seriousness, is there some sort of tips place
to give you money to fund the project? Although I don't have
much time (working on yet another cpu governor, amongst other
things), I can not eat at a restauraunt for lunch a couple of
times and send the money your way. :)
>> Also, how does this differ from what is currently in the vanilla
>> kernels?
>The best way to answer that is to point to
>http://swsusp.sourceforge.net/features.html.
Ah. Thankye.
A few last questions while I'm at it. (I'm struggling to get it to work
with my new Dell Inspiron 8600.) Is it alright to have the different
swsus/pmdisk versions enabled in the same kernel? Finally, is there
any specific way to create the swap space for saving the state to?
I created a swap partition (/dev/hda8 fwiw), made it type 82 and
ran mkswap on it. However, after I tried to suspend, it didn't
recognize the saved data.
-Joseph
Hi again.
On Sat, 2004-01-31 at 20:16, Joseph Pingenot wrote:
> >In the past I have only done patches against the 2.6.x kernels. I'm
> >thinking, however, of requesting space on kernel.org for patches against
> >-rcX and -mm kernels. You're the second person to ask. If I get asked
>
> That'd rock. It's a very important thing nowadays.
Okay. I'll ask then.
> >some more, I might do it :> (It's not that it's hard, just that it takes
>
> Hmm. Do I have to be a *new* person to ask, or can I just keep
> asking until you give in? ;)
:> Okay, okay, I give in! (That wasn't hard, was it?!)
> >time and today is my last day working on the code full time).
>
> Oi! I'll give you five (US) dollars. Is that near enough? :)
:>
> Actually, in all seriousness, is there some sort of tips place
> to give you money to fund the project? Although I don't have
> much time (working on yet another cpu governor, amongst other
> things), I can not eat at a restauraunt for lunch a couple of
> times and send the money your way. :)
Sourceforge have a donations thing now, but I haven't done my bit to
sign the project up for it. Frankly, after all the support LinuxFund
gave over the last four months, I'd rather encourage people to give to
them :>
> >> Also, how does this differ from what is currently in the vanilla
> >> kernels?
> >The best way to answer that is to point to
> >http://swsusp.sourceforge.net/features.html.
>
> Ah. Thankye.
>
> A few last questions while I'm at it. (I'm struggling to get it to work
> with my new Dell Inspiron 8600.) Is it alright to have the different
> swsus/pmdisk versions enabled in the same kernel? Finally, is there
Yes, I worked hard on making it play nicely with them. It does replace
the refrigerator they used, but if I've done it right and it hasn't been
broken it since (by any of the three of us), they shouldn't care.
> any specific way to create the swap space for saving the state to?
Suspend2 will use any swap space you have available. It will even
automatically turn on a swap partition or file for you at the start of
suspending, and turn it off at the end. It doesn't care about how the
swap space is distributed or whether it's a partition or a file or a
combination. Saving to local IDE and SCSI is tested, but I've had
limited success with SCSI due to the lack of power management on the
drives I was testing with (the machine resumed up to the point where it
wanted to use the SCSI drive again with the restored kernel, at which
point the driver paniced because the request numbers were out of sync).
> I created a swap partition (/dev/hda8 fwiw), made it type 82 and
> ran mkswap on it. However, after I tried to suspend, it didn't
> recognize the saved data.
2.6 has problems with flushing caches properly at the moment. It might
be related to that. I'd need more info to properly diagnose the problem.
Nigel
--
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.
Hi.
I rearranged things earlier today. The latest patch versions are now all
under the 'current' sections at the top of
http://sourceforge.net/project/showfiles.php?group_id=25964.
When I use -rev, I mean a revised version, just as you think, so I'd go
for
http://prdownloads.sourceforge.net/swsusp/software-suspend-linux-2.6.1-rev6-whole.bz2?download
and
http://prdownloads.sourceforge.net/swsusp/software-suspend-core-2.0-whole.bz2?download
and (as the instructions on http://swsusp.sf.net say), apply them in
that order.
Regards,
Nigel
On Sat, 2004-01-31 at 20:22, Luke-Jr wrote:
> What is considered the latest? rev implies that it would be a revision over
> the normal 2.6.1 patch...
--
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.
>From Nigel Cunningham on Saturday, 31 January, 2004:
>Hi again.
>On Sat, 2004-01-31 at 20:16, Joseph Pingenot wrote:
>> >In the past I have only done patches against the 2.6.x kernels. I'm
>> >thinking, however, of requesting space on kernel.org for patches against
>> >-rcX and -mm kernels. You're the second person to ask. If I get asked
>> That'd rock. It's a very important thing nowadays.
>Okay. I'll ask then.
>> >some more, I might do it :> (It's not that it's hard, just that it takes
>> Hmm. Do I have to be a *new* person to ask, or can I just keep
>> asking until you give in? ;)
>:> Okay, okay, I give in! (That wasn't hard, was it?!)
Yay! Yet again does annoyance reign victorious!
>> >time and today is my last day working on the code full time).
>>
>> Oi! I'll give you five (US) dollars. Is that near enough? :)
>:>
>> Actually, in all seriousness, is there some sort of tips place
>> to give you money to fund the project? Although I don't have
>> much time (working on yet another cpu governor, amongst other
>> things), I can not eat at a restauraunt for lunch a couple of
>> times and send the money your way. :)
>Sourceforge have a donations thing now, but I haven't done my bit to
>sign the project up for it. Frankly, after all the support LinuxFund
>gave over the last four months, I'd rather encourage people to give to
>them :>
Kewl beans. I'll see what I can do then.
>> >> Also, how does this differ from what is currently in the vanilla
>> >> kernels?
>> >The best way to answer that is to point to
>> >http://swsusp.sourceforge.net/features.html.
>> Ah. Thankye.
>> A few last questions while I'm at it. (I'm struggling to get it to work
>> with my new Dell Inspiron 8600.) Is it alright to have the different
>> swsus/pmdisk versions enabled in the same kernel? Finally, is there
>Yes, I worked hard on making it play nicely with them. It does replace
>the refrigerator they used, but if I've done it right and it hasn't been
>broken it since (by any of the three of us), they shouldn't care.
Cool. I think I'll disable the others just in case [you only need
*one* suspending mechanism].
>> any specific way to create the swap space for saving the state to?
>Suspend2 will use any swap space you have available. It will even
>automatically turn on a swap partition or file for you at the start of
>suspending, and turn it off at the end. It doesn't care about how the
>swap space is distributed or whether it's a partition or a file or a
>combination. Saving to local IDE and SCSI is tested, but I've had
>limited success with SCSI due to the lack of power management on the
>drives I was testing with (the machine resumed up to the point where it
>wanted to use the SCSI drive again with the restored kernel, at which
>point the driver paniced because the request numbers were out of sync).
Hmmm. Would turning on the swap space be a better option then? I had
left it off so that it wouldn't get used.
Something I was wondering about: what happens then if the swap space
is all filled? I liked having a dedicated partition so that that
wouldn't be an issue.
BTW, the drive in this is a plain IDE one.
>> ran mkswap on it. However, after I tried to suspend, it didn't
>> recognize the saved data.
>2.6 has problems with flushing caches properly at the moment. It might
>be related to that. I'd need more info to properly diagnose the problem.
Hmm. I'm hoping to take advantage of 2.6.2-rc3's ACPI updates
(I have some acpi wonkiness which is undoubtedly related to
Dell and its infamous DSDTs). Any chance you could make that
your first -rc target? :) I'll give you a lollipop whenever
I see you IRL.
Anyhow, I'm gonna hit the hay. Thanks for the great work; you're
truly an asset to Kiwi-dom. ;)
Howdy.
On Sat, 2004-01-31 at 20:38, Joseph Pingenot wrote:
> Yay! Yet again does annoyance reign victorious!
Well, I wouldn't really count two requests from two people as annoyance
:>
> >> any specific way to create the swap space for saving the state to?
> >Suspend2 will use any swap space you have available. It will even
> >automatically turn on a swap partition or file for you at the start of
> >suspending, and turn it off at the end. It doesn't care about how the
> >swap space is distributed or whether it's a partition or a file or a
> >combination. Saving to local IDE and SCSI is tested, but I've had
> >limited success with SCSI due to the lack of power management on the
> >drives I was testing with (the machine resumed up to the point where it
> >wanted to use the SCSI drive again with the restored kernel, at which
> >point the driver paniced because the request numbers were out of sync).
>
> Hmmm. Would turning on the swap space be a better option then? I had
> left it off so that it wouldn't get used.
It depends how much swap gets used in your normal activity. A good rule
of thumb is to make sure you have as much swap as RAM, plus a little
more for any genuine swapping the system is doing. Then you'll be able
to save a full image without freeing up any memory... and when you do
resume, your system will be as responsive as it would be if you'd never
suspended.
> Something I was wondering about: what happens then if the swap space
> is all filled? I liked having a dedicated partition so that that
> wouldn't be an issue.
If there's not swap space to store the image in, suspend tries to free
memory until there is. In the worst case, it will reach a point where it
can't free any more memory, give up and cleanly back out. (Or that's the
plan, another email I just received means I will shortly double check
this is happening correctly under 2.6).
> Hmm. I'm hoping to take advantage of 2.6.2-rc3's ACPI updates
> (I have some acpi wonkiness which is undoubtedly related to
> Dell and its infamous DSDTs). Any chance you could make that
> your first -rc target? :) I'll give you a lollipop whenever
> I see you IRL.
Haha! See what I can do.
Nigel
> Anyhow, I'm gonna hit the hay. Thanks for the great work; you're
> truly an asset to Kiwi-dom. ;)
Thank you.
Nigel
--
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 31 January 2004 08:09 am, Luke-Jr wrote:
> After merging drivers/char/keyboard.c by hand (patch didn't like
> something):
> <snip>
Undo that message... >_>
Forgot the core patch after merging keyboard.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAG2NPZl/BHdU+lYMRAkTEAJ4usaB5B9fak1xjTJkNGgWRajcH8gCgmGMt
4LynWpeLGwL0g91RfLiXDbM=
=ypsu
-----END PGP SIGNATURE-----
Hmm.
If linux/suspend.h is missing, you probably didn't apply the core patch.
Regards,
Nigel
On Sat, 2004-01-31 at 21:09, Luke-Jr wrote:
> init/do_mounts.c:6:27: linux/suspend.h: No such file or directory
--
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 31 January 2004 07:31 am, Nigel Cunningham wrote:
> http://prdownloads.sourceforge.net/swsusp/software-suspend-linux-2.6.1-rev6
>-whole.bz2?download
> http://prdownloads.sourceforge.net/swsusp/software-suspend-core-2.0-whole.b
>z2?download
> and (as the instructions on http://swsusp.sf.net say), apply them in
> that order.
After merging drivers/char/keyboard.c by hand (patch didn't like something):
CC init/do_mounts.o
init/do_mounts.c:6:27: linux/suspend.h: No such file or directory
In file included from include/linux/nfs_fs.h:15,
from init/do_mounts.c:10:
include/linux/pagemap.h:13:27: linux/suspend.h: No such file or directory
In file included from include/linux/nfs_fs.h:15,
from init/do_mounts.c:10:
include/linux/pagemap.h: In function `___add_to_page_cache':
include/linux/pagemap.h:150: error: `suspend_task' undeclared (first use in
this function)
include/linux/pagemap.h:150: error: (Each undeclared identifier is reported
only once
include/linux/pagemap.h:150: error: for each function it appears in.)
include/linux/pagemap.h:151: error: `last_suspend_cache_page' undeclared
(first use in this function)
make[1]: *** [init/do_mounts.o] Error 1
make: *** [init] Error 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAG2LIZl/BHdU+lYMRAsUrAKCYq15FX/pRdIi7OAH1IwEtUn5+eQCfdWp2
zFd+CIqpePi4+S54x1DIHPM=
=0QIi
-----END PGP SIGNATURE-----
Okay. Attached is a patch that will let you use Software Suspend 2.0
with linux-2.6.2-rc3.
How to apply:
Get the latest 2.6.1 patch (revision 7) and latest core patch (2.0) from
http://swsusp.sf.net.
Apply the 2.6.1 patch to your rc3 kernel. You'll get some rejects; don't
worry about them. Apply the attached patch. It fixes up the rejects. Now
apply the core patch. Then configure and compile as per normal.
Regards,
Nigel
--
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.
Hi.
On Sat, 2004-01-31 at 22:03, Prakash K. Cheemplavam wrote:
> > Get the latest 2.6.1 patch (revision 7) and latest core patch (2.0) from
> > http://swsusp.sf.net.
>
> I am sorry, I only see a rev 6 patch. Will that also work?
You're right. I got the revision number for 2.4.24 stuck in my head.
rev6 is the right one.
Nigel
--
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.
Nigel Cunningham wrote:
> Okay. Attached is a patch that will let you use Software Suspend 2.0
> with linux-2.6.2-rc3.
Yes!
> Get the latest 2.6.1 patch (revision 7) and latest core patch (2.0) from
> http://swsusp.sf.net.
I am sorry, I only see a rev 6 patch. Will that also work?
Prakash
Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2004-01-31 at 22:03, Prakash K. Cheemplavam wrote:
>
>>>Get the latest 2.6.1 patch (revision 7) and latest core patch (2.0) from
>>>http://swsusp.sf.net.
>>
>>I am sorry, I only see a rev 6 patch. Will that also work?
>
>
> You're right. I got the revision number for 2.4.24 stuck in my head.
> rev6 is the right one.
Ok, just trying it out. So far:
Doing the kernel patch to 2.6.2-rc3, it asks me about a file missing in
xfs. I skipped it. Then I used your patch you sent to lkml to fix things
up. Finally I applied the core patch. Now it asks me
The next patch would create the file kernel/power/swsusp2.c,
which already exists! Assume -R? [n]
Should this happen? What to do now?
Prakash
No. The freezer changes would be the only related part.
Regards,
Nigel
On Sat, 2004-01-31 at 22:35, ?ric Brunet wrote:
> In linux-kernel, you wrote:
> >> Also, how does this differ from what is currently in the vanilla
> >> kernels?
> >
> > The best way to answer that is to point to
> > http://swsusp.sourceforge.net/features.html.
>
> No doubt that one day your work will be integrated, but will it help
> suspend to ram (acpi sleep state 3) ?
>
> Thank you,
>
> ?ric Brunet
--
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.
In linux-kernel, you wrote:
>> Also, how does this differ from what is currently in the vanilla
>> kernels?
>
> The best way to answer that is to point to
> http://swsusp.sourceforge.net/features.html.
No doubt that one day your work will be integrated, but will it help
suspend to ram (acpi sleep state 3) ?
Thank you,
?ric Brunet
Hi.
My error. My patch script has put kernel/power/swsusp2.c in the version
specific patch and I didn't notice. Just ignore the reject when you
apply the core patch and you should be okay (there is a small change
that belongs in the next core patch).
Humble apologies,
Nigel
On Sat, 2004-01-31 at 22:19, Prakash K. Cheemplavam wrote:
> Ok, just trying it out. So far:
>
> Doing the kernel patch to 2.6.2-rc3, it asks me about a file missing in
> xfs. I skipped it. Then I used your patch you sent to lkml to fix things
> up. Finally I applied the core patch. Now it asks me
>
> The next patch would create the file kernel/power/swsusp2.c,
> which already exists! Assume -R? [n]
>
> Should this happen? What to do now?
>
> Prakash
--
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.
> My error. My patch script has put kernel/power/swsusp2.c in the version
No problem. I already tested it. After throwing out usb modules, it did
suspend, though taking quite long at the kernel and processing
(something like that) message. But upon restart, it didn't resume, ie.
it didn't find its image, just normal swap space.
I compiled into kernel /dev/hde5 and put resume2=swap:/dev/hde5 into
kernel paramters at grung.conf. Shouldn't that work?
bye,
Prakash
Prakash K. Cheemplavam wrote:
> I compiled into kernel /dev/hde5 and put resume2=swap:/dev/hde5 into
> kernel paramters at grung.conf. Shouldn't that work?
It should be "grub.conf", of course.
Prakash
"Prakash K. Cheemplavam" <[email protected]> writes:
>> My error. My patch script has put kernel/power/swsusp2.c in the version
>
> No problem. I already tested it. After throwing out usb modules, it
> did suspend, though taking quite long at the kernel and processing
> (something like that) message. But upon restart, it didn't resume,
> ie. it didn't find its image, just normal swap space.
Try disabling write cache on the disk with hdparm -W0 /dev/hde.
--
M?ns Rullg?rd
[email protected]
On Fri, 2004-01-30 at 05:24, Nigel Cunningham wrote:
> Finally, heres a little ditty, to be sung to the tune of the 'The
> Pirates Who Don't Do Anything'
> (http://www.bassbios.com/bodclan/pirates.mp3)
First of all, congratulations to everyone contributing to swsusp, great
work! Runs fast and stable here with 2.4.24, surely something I wouldn't
want to miss on my Laptop. Suspending takes about 15 sec, resuming about
half a minute. No problems with drivers, no unloading of modules is
necessary. Also bootsplash does look very 'sexy' with swsusp.
Secondly, and 'somewhat offtopic': How the heck do I get rid of this
ditty stuck in my head? ;-)
--
Regards,
sebas
-------------------------------
If the path be beautiful, let us not ask where it leads. -- Anatole
France
I made a patch against 2.6.2-rc2 to fix the rejects which hasn't seemed
to make it to the list yet so I will attach again.
Note that the rejects are easy to fix but there is a problem with
sysctl.c where the #endif belonging to the #ifdef KDB goes way off spot
so the kernel doesn't link.
On Fri, Jan 30, 2004 at 11:25:28PM +1300, Nigel Cunningham wrote:
> Ah. I see. It's not out, but you want bleeding edge :>
>
> > The patches fail on a 2.6.2-rc2 kernel. Are there any patches for
> > post-2.6.1 kernels?
> --
> My work on Software Suspend is graciously brought to you by
> LinuxFund.org.
>
> -
> 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/
>
>From M?ns Rullg?rd on Saturday, 31 January, 2004:
>"Prakash K. Cheemplavam" <[email protected]> writes:
>>> My error. My patch script has put kernel/power/swsusp2.c in the version
>> No problem. I already tested it. After throwing out usb modules, it
>> did suspend, though taking quite long at the kernel and processing
>> (something like that) message. But upon restart, it didn't resume,
>> ie. it didn't find its image, just normal swap space.
>Try disabling write cache on the disk with hdparm -W0 /dev/hde.
When should this be done?
I have 2.6.1 + the 2.6.1-specific patches + core patches. It suspends
without difficulty, but on boot, it says it couldn't read a part
of the resume data (a "chunk", iirc). The status bar doesn't make
much progress.
I tried hdparm -W 0 right before the call to hibernate (in a script).
But I still have the problem.
When should hdparm be called?
Thanks!
-Joseph
Joseph Pingenot <[email protected]> writes:
> From M?ns Rullg?rd on Saturday, 31 January, 2004:
>>"Prakash K. Cheemplavam" <[email protected]> writes:
>>>> My error. My patch script has put kernel/power/swsusp2.c in the version
>>> No problem. I already tested it. After throwing out usb modules, it
>>> did suspend, though taking quite long at the kernel and processing
>>> (something like that) message. But upon restart, it didn't resume,
>>> ie. it didn't find its image, just normal swap space.
>>Try disabling write cache on the disk with hdparm -W0 /dev/hde.
>
> When should this be done?
>
> I have 2.6.1 + the 2.6.1-specific patches + core patches. It suspends
> without difficulty, but on boot, it says it couldn't read a part
> of the resume data (a "chunk", iirc). The status bar doesn't make
> much progress.
>
> I tried hdparm -W 0 right before the call to hibernate (in a script).
That did the trick for me. You must be having a different problem.
> But I still have the problem.
>
> When should hdparm be called?
>
> Thanks!
>
> -Joseph
--
M?ns Rullg?rd
[email protected]
On Sat, Jan 31, 2004 at 05:11:37PM -0600, Joseph Pingenot wrote:
> >From M?ns Rullg?rd on Saturday, 31 January, 2004:
> >"Prakash K. Cheemplavam" <[email protected]> writes:
> >>> My error. My patch script has put kernel/power/swsusp2.c in the version
> >> No problem. I already tested it. After throwing out usb modules, it
> >> did suspend, though taking quite long at the kernel and processing
> >> (something like that) message. But upon restart, it didn't resume,
> >> ie. it didn't find its image, just normal swap space.
> >Try disabling write cache on the disk with hdparm -W0 /dev/hde.
>
> When should this be done?
>
> I have 2.6.1 + the 2.6.1-specific patches + core patches. It suspends
> without difficulty, but on boot, it says it couldn't read a part
> of the resume data (a "chunk", iirc). The status bar doesn't make
> much progress.
>
> I tried hdparm -W 0 right before the call to hibernate (in a script).
> But I still have the problem.
>
> When should hdparm be called?
>
Is X running with dri support? If so as a start try stopping X and see
if that solves your problem (there is still a problem with most of the
agp and drm drivers suspend support)
> Thanks!
>
> -Joseph
> -
> 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/
>
This happened once with rc-1 vanilla and once with rc-3 (haven't used
rc2 long enough.) Never happened with a earlier kernel. The message
repeats eternally itself making the system next to unusuable.
Any idea how to fix it?
I am using siimage ide driver.
Prakash
Feb 1 02:34:48 tachyon handlers:
Feb 1 02:34:48 tachyon [<c02a6b50>] (ide_intr+0x0/0x190)
Feb 1 02:34:48 tachyon [<c03248c0>] (snd_intel8x0_interrupt+0x0/0x210)
Feb 1 02:34:48 tachyon Disabling IRQ #11
Feb 1 02:34:48 tachyon irq 11: nobody cared!
Feb 1 02:34:48 tachyon Call Trace:
Feb 1 02:34:48 tachyon [<c010b0aa>] __report_bad_irq+0x2a/0x90
Feb 1 02:34:48 tachyon [<c010b19c>] note_interrupt+0x6c/0xb0
Feb 1 02:34:48 tachyon [<c010b451>] do_IRQ+0x121/0x130
Feb 1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
Feb 1 02:34:48 tachyon [<c0124080>] do_softirq+0x40/0xa0
Feb 1 02:34:48 tachyon [<c010b42d>] do_IRQ+0xfd/0x130
Feb 1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
Feb 1 02:34:48 tachyon [<c0281056>] generic_unplug_device+0x26/0x80
Feb 1 02:34:48 tachyon [<c028121a>] blk_run_queues+0x7a/0xb0
Feb 1 02:34:48 tachyon [<c016605f>] __wait_on_buffer+0xbf/0xd0
Feb 1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
Feb 1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
Feb 1 02:34:48 tachyon [<c020dbb8>] submit_logged_buffer+0x38/0x60
Feb 1 02:34:48 tachyon [<c020e1a3>] kupdate_one_transaction+0x1b3/0x210
Feb 1 02:34:48 tachyon [<c020e275>] reiserfs_journal_kupdate+0x75/0xb0
Feb 1 02:34:48 tachyon [<c0210ed4>] flush_old_commits+0x144/0x1d0
Feb 1 02:34:48 tachyon [<c0122583>] do_exit+0x293/0x500
Feb 1 02:34:48 tachyon [<c01fe942>] reiserfs_write_super+0x82/0x90
Feb 1 02:34:48 tachyon [<c016b94c>] sync_supers+0xac/0xc0
Feb 1 02:34:48 tachyon [<c014b526>] wb_kupdate+0x36/0x120
Feb 1 02:34:48 tachyon [<c02602d3>] tty_write+0x1d3/0x3f0
Feb 1 02:34:48 tachyon [<c026008e>] tty_read+0x18e/0x200
Feb 1 02:34:48 tachyon [<c011c86d>] schedule+0x31d/0x590
Feb 1 02:34:48 tachyon [<c01214c0>] reparent_to_init+0xf0/0x180
Feb 1 02:34:48 tachyon [<c014bb4b>] __pdflush+0xcb/0x1b0
Feb 1 02:34:48 tachyon [<c014bc30>] pdflush+0x0/0x20
Feb 1 02:34:48 tachyon [<c014bc3f>] pdflush+0xf/0x20
Feb 1 02:34:48 tachyon [<c014b4f0>] wb_kupdate+0x0/0x120
Feb 1 02:34:48 tachyon [<c0107284>] kernel_thread_helper+0x0/0xc
Feb 1 02:34:48 tachyon [<c0107289>] kernel_thread_helper+0x5/0xc
Feb 1 02:34:48 tachyon
On Sun, Feb 01, 2004 at 02:48:28AM +0100, Prakash K. Cheemplavam wrote:
> This happened once with rc-1 vanilla and once with rc-3 (haven't used
> rc2 long enough.) Never happened with a earlier kernel. The message
> repeats eternally itself making the system next to unusuable.
>
> Any idea how to fix it?
>
> I am using siimage ide driver.
>
> Prakash
>
> Feb 1 02:34:48 tachyon handlers:
> Feb 1 02:34:48 tachyon [<c02a6b50>] (ide_intr+0x0/0x190)
> Feb 1 02:34:48 tachyon [<c03248c0>] (snd_intel8x0_interrupt+0x0/0x210)
> Feb 1 02:34:48 tachyon Disabling IRQ #11
> Feb 1 02:34:48 tachyon irq 11: nobody cared!
This irq message has been reported by several people (including me), I
don't think there is a solution yet. AFAIK its not swsusp related.
> Feb 1 02:34:48 tachyon Call Trace:
> Feb 1 02:34:48 tachyon [<c010b0aa>] __report_bad_irq+0x2a/0x90
> Feb 1 02:34:48 tachyon [<c010b19c>] note_interrupt+0x6c/0xb0
> Feb 1 02:34:48 tachyon [<c010b451>] do_IRQ+0x121/0x130
> Feb 1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
> Feb 1 02:34:48 tachyon [<c0124080>] do_softirq+0x40/0xa0
> Feb 1 02:34:48 tachyon [<c010b42d>] do_IRQ+0xfd/0x130
> Feb 1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
> Feb 1 02:34:48 tachyon [<c0281056>] generic_unplug_device+0x26/0x80
> Feb 1 02:34:48 tachyon [<c028121a>] blk_run_queues+0x7a/0xb0
> Feb 1 02:34:48 tachyon [<c016605f>] __wait_on_buffer+0xbf/0xd0
> Feb 1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
> Feb 1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
> Feb 1 02:34:48 tachyon [<c020dbb8>] submit_logged_buffer+0x38/0x60
> Feb 1 02:34:48 tachyon [<c020e1a3>] kupdate_one_transaction+0x1b3/0x210
> Feb 1 02:34:48 tachyon [<c020e275>] reiserfs_journal_kupdate+0x75/0xb0
> Feb 1 02:34:48 tachyon [<c0210ed4>] flush_old_commits+0x144/0x1d0
> Feb 1 02:34:48 tachyon [<c0122583>] do_exit+0x293/0x500
> Feb 1 02:34:48 tachyon [<c01fe942>] reiserfs_write_super+0x82/0x90
> Feb 1 02:34:48 tachyon [<c016b94c>] sync_supers+0xac/0xc0
> Feb 1 02:34:48 tachyon [<c014b526>] wb_kupdate+0x36/0x120
> Feb 1 02:34:48 tachyon [<c02602d3>] tty_write+0x1d3/0x3f0
> Feb 1 02:34:48 tachyon [<c026008e>] tty_read+0x18e/0x200
> Feb 1 02:34:48 tachyon [<c011c86d>] schedule+0x31d/0x590
> Feb 1 02:34:48 tachyon [<c01214c0>] reparent_to_init+0xf0/0x180
> Feb 1 02:34:48 tachyon [<c014bb4b>] __pdflush+0xcb/0x1b0
> Feb 1 02:34:48 tachyon [<c014bc30>] pdflush+0x0/0x20
> Feb 1 02:34:48 tachyon [<c014bc3f>] pdflush+0xf/0x20
> Feb 1 02:34:48 tachyon [<c014b4f0>] wb_kupdate+0x0/0x120
> Feb 1 02:34:48 tachyon [<c0107284>] kernel_thread_helper+0x0/0xc
> Feb 1 02:34:48 tachyon [<c0107289>] kernel_thread_helper+0x5/0xc
> Feb 1 02:34:48 tachyon
I didn't check it in the kernel but at first sight it looks like
regular disks updates. I don't know what it goes into a loop. Are you
sure that you don't have something that keeps updating the disk?
>
> -
> 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/
>