Announce: Swsusp-2.0-2.6-alpha1

Hi all.

I'm pleased to be able to announce the first test release of a port of the current 2.0 pre-release Software Suspend code to 2.6. This is now available from www.sourceforge.net/projects/swsusp and bk://swsusp25.bkbits.net/main.

Release notes:
- The patch is prepared against current bk. It should apply against test8 with minimal and perhaps no fuss.
- Breaks current Software Suspend implementations in the kernel. Apologies to Patrick and Pavel. I won't be leaving it this way for long, I promise!
- I/O is slow and jerky. I need to investigate the cause for this further; something in the hooks to the new bio code is not quite right.

Apart from the above, and the normal problems with incomplete driver support will continue. In addition, you may see freezing failures. If the process hangs at 'Freezing processes: Waiting for activity to finish' or 'Syncing remaining I/O', try pressing escape once. If the process doesn't abort, try a second time (which tries harder to restart things). All going well, you should be able to cancel the suspend. A log of what went wrong will be stored in /var/log/messages. Run it through ksymoops if necessary and send it to me, and I should be able to address the issue.

Please send feedback via the Software Suspend mailing list on Sourceforge. See http://swsusp.sf.net for FAQs, mailing list details and so on. Because the code is essentially the same as the 2.4 version, many of the solutions to issues will be the same.

As always, I look forward to hearing feedback.

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.

The SourceForge page shows the 2.0-2.6-alpha1 patch is dated May 2003. How is this possible?

Ah. That section (which used to contain patches against 2.5.67) was made in May. I'll update the date.

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,

website: the ML section should point to the sf.net website where you can subscribe to the ML. Else lazy people like me will simply post to linux-kernel :-)

The suspend shell script touches /tmp/suspend.$$. I don't know, but maybe that is a securitry problem? People always recommend to use tmpfile to create temporary files, so noone can guess the name and create evil symlinks to /etc/passwd and friends. I don't know if a touch is also a problem.

Maybe add some documentation: swsusp does not use the bios, I guess? PM_DISK seems to use, and the acpi does allow both (4 for swsusp, 4b for bios based)? I don't have a special partition the dell bios will accept, so I can only try swsusp for now.

Also, maybe add some documentation on how to integrate with ACPI? many laptops have a function button and special keys to trigger suspend (e.g. fn+esc on my machine). This triggers the suspend event via /proc/acpi/events. I wrote a simple config and shell script, but found one issue other people might have,
too: acpi creates one such even for pressing the key and one for releasing the key. if the shell script only does "echo 4 > /proc/acpi/suspend", then the first resume will put the machine to sleep right again. I didn't look at the suspend.sh in
detail: will it detect such double calls and somehow ignore the release event?

And last: it does not compile at all for me:
CC kernel/power/proc.o
kernel/power/proc.c: In function `swsusp_write_proc':
kernel/power/proc.c:259: error: `debug_sections' undeclared (first use in this function) kernel/power/proc.c:259: error: (Each undeclared identifier is reported only once kernel/power/proc.c:259: error: for each function it appears in.)
make[2]: *** [kernel/power/proc.o] Error 1
make[1]: *** [kernel/power] Error 2
make: *** [kernel] Error 2

and there are some new warnings:
CC kernel/power/io.o
kernel/power/io.c: In function `__read_primary_suspend_image':
kernel/power/io.c:845: warning: unused variable headerblocksize' kernel/power/io.c: In function read_primary_suspend_image':
kernel/power/io.c:1106: warning: unused variable `blksize'

config:
http://athene.wiwi.uni-karlsruhe.de/~aj/config-2.6.0-test8-swsusp

and I find this quite strage in the documentation:
Since 2.4 kernels don't have the driver model that's being developed
...

huh? it's the kernel 2.6. documentation. maybe that file was simply copied from 2.4? updating it could reduce some confusion :-)

Andreas

hurrah!

The attached patch allowed the kernel to compile for me, haven't booted into it as yet.

thanks Nigel,
iain

"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -- St. Augustine

@@ -1506,7 +1506,7 @@
 
 	daemonize("scsi_eh_%d", shost->host_no);
 
-	current->flags |= PF_IOTHREAD;
+	current->flags |= PF_NOFREEZE;
 
 	shost->eh_wait = &sem;
 	shost->ehandler = current;

when trying to suspend (either by directly echoing > /proc/swsusp/activate, or with the script) It only gets as far as the first screen "killing processes/freeing space" (can't remember the exact message despite staring at it for a good 20 mins total today)

the 'r' and 'l' keys both change the message, toggling reboot and logging respectively, but no other keys have any effect.

cheers,
iain

"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -- St. Augustine

You should be able to press escape to cancel; if the message stays for more than a couple of seconds, something is wrong. When you cancel, you should get messages in the log that will help me diagnose and fix the issue. You may need to run them through ksymoops to convert hex to procedure names.

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.

Sorry, I forgot to mention that I did try hitting escape, with zero response.

I also saw no swsusp messages in /var/log/messages beyond the startup 'resume device set to /dev/hda1' lines.

iain

"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -- St. Augustine