swsusp bootsplash support
Subsystems (2)
PATCH 1/1 swsusp bootsplash support
This patch adds support for bootsplash to swsusp. The code interfacing to bootsplash needs some more work, currently it's more or less ripped from swsusp2. Some more code could probably be moved into console.c instead.
Erik
kernel/power/console.c +16 -4
@@ -8,6 +8,7 @@#include <linux/kbd_kern.h> #include <linux/console.h> #include "power.h" +#include "splash.h" static int new_loglevel =10 ;static int orig_loglevel;
@@ -30,13 +31,24 @@ return 1; } -set_console (SUSPEND_CONSOLE ); +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) +set_console (SUSPEND_SPLASH_CONSOLE ); +else +set_console (SUSPEND_CONSOLE );release_console_sem (); -if (vt_waitactive (SUSPEND_CONSOLE )) { -pr_debug ("Suspend: Can't switch VCs." ); -return 1 ; +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) { +if (vt_waitactive (SUSPEND_SPLASH_CONSOLE )) { +pr_debug ("Suspend: Can't switch VCs." ); +return 1 ; + } + }else { +if (vt_waitactive (SUSPEND_CONSOLE )) { +pr_debug ("Suspend: Can't switch VCs." ); +return 1 ; + } } + orig_kmsg = kmsg_redirect; kmsg_redirect =SUSPEND_CONSOLE ;#endif
kernel/power/Makefile +1 -1
@@ -1,5 +1,5 @@ obj-y := main.o process.o console.o pm.o -obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o +obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o splash.o obj-$(CONFIG_PM_DISK) += disk.o pmdisk.o obj-$(CONFIG_MAGIC_SYSRQ) += poweroff.o
kernel/power/splash.c +112 -0
112 lines not on this page · raw message
kernel/power/splash.h +21 -0
@@ -0,0 +1,21 @@ +#ifndef _SPLASH_H +#define _SPLASH_H + +#define SUSPEND_SPLASH_CONSOLE 0 + +#if defined(CONFIG_PROC_FS ) && defined(CONFIG_BOOTSPLASH ) + +int splash_is_on (int consolenr); +void splash_write_proc (const char *buffer,unsigned long count); +int splash_set_progress (unsigned long value,unsigned long maximum); + +#else +#define splash_is_on (consolenr) (0) +#define splash_set_progress (...) do { } while(0) +#define splash_write_proc (...) do { } while(0) +#endif + +#define splash_set_verbose () splash_write_proc("verbose\n", 9); +#define splash_set_silent () splash_write_proc("silent\n", 8); + +#endif
kernel/power/swsusp.c +25 -7
@@ -69,6 +69,7 @@#include <asm/io.h> #include "power.h" +#include "splash.h" unsigned char software_suspend_enabled =0 ;
@@ -312,11 +313,15 @@if (!buffer)return -ENOMEM ; - +printk ("Writing data to swap (%d pages): " , nr_copy_pages );for (i=0 ; i<nr_copy_pages; i++) { -if (!(i%100 )) +if (!(i%100 )) { +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) +splash_set_progress (i, nr_copy_pages);printk ("." ); + } +if (!(entry =get_swap_page ()).val)panic ("\nNot enough swapspace when writing data" );
@@ -829,6 +834,12 @@ }if (pm_prepare_console ())printk ("%sCan't allocate a console... proceeding\n" , name_suspend); + +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) { +splash_set_progress (0 ,1 ); +splash_set_silent (); + } +if (!prepare_suspend_processes ()) {/* At this point, all user processes and "dangerous"
@@ -855,6 +866,10 @@ software_suspend_enabled =1 ;MDELAY (1000 );pm_restore_console (); + +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) +splash_set_verbose (); +return res; }
@@ -1067,6 +1082,9 @@printk ("%sSignature found, resuming\n" , name_resume );MDELAY (1000 ); +if (pm_prepare_console ()) +printk ("swsusp: Can't allocate a console... proceeding\n" ); +if (bdev_read_page (bdev, next.val, cur))return -EIO ;if (sanity_check (&cur->sh))/* Is this same machine? */ return -EPERM ;
@@ -1100,8 +1118,12 @@printk ("Reading image data (%d pages): " , nr_copy_pages );for (i=0 ; i < nr_copy_pages; i++) {swp_entry_t swap_address = (pagedir_nosave+i)->swap_address; -if (!(i%100 )) +if (!(i%100 )) { +if (splash_is_on (SUSPEND_SPLASH_CONSOLE )) +splash_set_progress (i, nr_copy_pages);printk ("." ); + } +/* You do not need to check for overlaps... ... check_pagedir already did this work */ if (bdev_read_page (bdev,swp_offset (swap_address) *PAGE_SIZE , (char *)((pagedir_nosave+i)->address)))
@@ -1190,9 +1212,6 @@ }MDELAY (1000 ); -if (pm_prepare_console ()) -printk ("swsusp: Can't allocate a console... proceeding\n" ); -if (!resume_file[0 ] && resume_status ==RESUME_SPECIFIED ) {printk ("suspension device unspecified\n" );return -EINVAL ;
@@ -1206,7 +1225,6 @@panic ("This never returns" ); read_failure: -pm_restore_console ();return 0 ; }
Quoted 3 lines · Erik Rigtorp
This patch adds support for bootsplash to swsusp. The code interfacing to bootsplash needs some more work, currently it's more or less ripped from swsusp2. Some more code could probably be moved into
console.cinstead.
CONFIG_BOOTSPALSH (foruntatley) isn't in mainline, so while you're of course free to keep this patch around it has no business at all in mainline.
Hi!
Quoted 6 lines
Quoted 3 lines
This patch adds support for bootsplash to swsusp. The code interfacing to bootsplash needs some more work, currently it's more or less ripped from swsusp2. Some more code could probably be moved into
console.cinstead.
CONFIG_BOOTSPALSH(foruntatley) isn't in mainline, so while you're of course free to keep this patch around it has no business at all in mainline.
The patch was not intended for mainline... But it will be usefull anyway as big distros want this kind of stuff....
Perhaps CONFIG_BOOTSPLASH should be in mainline after all? I really don't want to see 2 different incompatible sets of hooks into swsusp....
Pavel
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Quoted 3 lines
Perhaps
CONFIG_BOOTSPLASHshould be in mainline after all? I really don't want to see 2 different incompatible sets of hooks into swsusp....
No. This stuff has no business in the kernel, paint your fancy graphics ontop of fbdev. And the SuSE bootsplash patch is utter crap, I mean what do you have to smoke to put a jpeg decoder into the kernel?
Hi!
Quoted 7 lines
Quoted 3 lines
Perhaps
CONFIG_BOOTSPLASHshould be in mainline after all? I really don't want to see 2 different incompatible sets of hooks into swsusp....No. This stuff has no business in the kernel, paint your fancy graphics ontop of fbdev. And the SuSE bootsplash patch is utter crap, I mean what do you have to smoke to put a jpeg decoder into the kernel?
No idea; smoking is prohibited in SuSE offices, so someone external had to do that ;-).
I have not seen SuSE version of bootsplash... I do not want to see. But this way, SuSE has its own crappy bootsplash, RedHat probably too, Mandrake probably too, etc.
And now, SUSE will want splash over swsusp, RedHat probably too, Madrake probably too, etc. I do not want to deal with 3 different sets of hooks into swsusp.
Now.. Perhaps cleaned-up bootsplash could find its way into kernel. That would at least turn down ammount of crap in distributions. At least there would be unified way to turn that thing off...
Or at least standartized hooks for various splashes, so that I do not have to deal with 3 different sets?
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 3 lines · Pavel Machek
I have not seen SuSE version of bootsplash... I do not want to see. But this way, SuSE has its own crappy bootsplash, RedHat probably too, Mandrake probably too, etc.
Red Hat gets it right and uses a program that's using fbdev. They also have no swsusp support, which makes quite a lot of sense given how much in flux the code still is.
Quoted 6 lines · Christoph Hellwig
Quoted 3 lines · Pavel Machek
I have not seen SuSE version of bootsplash... I do not want to see. But this way, SuSE has its own crappy bootsplash, RedHat probably too, Mandrake probably too, etc.
Red Hat gets it right and uses a program that's using fbdev.
That program is called X 8-)
Dave
Hi!
Quoted 7 lines
Quoted 3 lines
I have not seen SuSE version of bootsplash... I do not want to see. But this way, SuSE has its own crappy bootsplash, RedHat probably too, Mandrake probably too, etc.
Red Hat gets it right and uses a program that's using fbdev. They also have no swsusp support, which makes quite a lot of sense given how much in flux the code still is.
Okay, if redhat is actually doing it right, there's no reason for encouraging the wrong thing.
But I guess swsusp is going to make this more "interesting" as progressbar is nice to have there, and userland can not help at that point.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 3 lines · Pavel Machek
But I guess swsusp is going to make this more "interesting" as progressbar is nice to have there, and userland can not help at that point.
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
Dave
Hi.
Quoted 3 lines · Dave Jones
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
That's happening. I'm hoping to merge Suspend2 within the week. It has support for SMP, Highmem (4GB), preempt, PPC (courtesy Steve & Ben), X86-64 (being finished by 'Disconnect' right now), x86, image compression and bootsplash. An NFS image writer is also planned.
Regards,
Nigel
Hi,
Quoted 11 lines · Nigel Cunningham
Hi.
Quoted 3 lines · Dave Jones
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
That's happening. I'm hoping to merge Suspend2 within the week. It has support for SMP, Highmem (4GB), preempt, PPC (courtesy Steve & Ben), X86-64 (being finished by 'Disconnect' right now), x86, image compression and bootsplash. An NFS image writer is also planned.
Can I find suspend2 broken on individual patches somewhere?
Hi.
That patches are available from swsusp.sf.net (look in the 'Test patches' section at the bottom of the download page for the latest patches I've released). The .tar.gz's contain everything needed for suspend, plus other patches that might be helpful to the user. They should be applied to a vanilla kernel in order. They aren't yet broken up into separate patches for merging. That will be my task next week.
Regards,
Nigel
Quoted 3 lines · Dave Jones
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
Miniority? Well both swsusp and pmdisk has worked on the majority of machines I've come across. From what I understand swsusp works on almost all x86 uniprocessor machines and that's a lot of machines. Some drivers are a hassle though.
Erik
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Erik" == Erik Rigtorp <[email protected]> writes:
Quoted 3 lines · Dave Jones
Quoted 3 lines
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
Erik> Miniority? Well both swsusp and pmdisk has worked on the majority Erik> of machines I've come across. From what I understand swsusp works Erik> on almost all x86 uniprocessor machines and that's a lot of Erik> machines. Some drivers are a hassle though.
FWIW, I have been using Nigel's swsusp2 for a long time now on a 2.4 kernel. It has been exceptionally well-behaved and stable. And it's an extremely important part of my Linux world. I will not move to 2.6 unless I'm sure swsusp2 will work well.
In fact, it seems to me that many kernel developers underestimate the importance of software suspend to actual real Linux users. I guess when you reboot your monster PC rig five times a day to upgrade kernels, you don't much care. But if you use a laptop and you actually care about opening it and getting a stable, working environment within 20s, trust me -- software suspend becomes more important to you than all the scheduler improvements in the world.
I would gladly trade all the performance improvements of the last couple of years for a stable, working swsusp2 and a USB subsystem which doesn't
a) prohibit my CPU from using C3 sleep and b) crash and burn regularly bringing the whole machine down with it.
--J.
On Monday 12 July 2004 06:43, Jan Rychter wrote:
...
Quoted 9 lines
upgrade kernels, you don't much care. But if you use a laptop and you actually care about opening it and getting a stable, working environment within 20s, trust me -- software suspend becomes more important to you than all the scheduler improvements in the world.
I would gladly trade all the performance improvements of the last couple of years for a stable, working swsusp2 and a USB subsystem which doesn't a) prohibit my CPU from using C3 sleep and b) crash and burn regularly bringing the whole machine down with it.
I'll second this. I moved to 2.6 because I needed a slew of drivers that were difficult to patch into 2.4 or out of date or etc. However, I haven't had a working 2.6 swsusp for probably 4 months or so (since I stopped using the 2.6.3 version after it ate my ext3 journal on my root partition).
I suppose I could look at going back to 2.4....
Signature · 1 line
Eric Altendorf // http://www.speedtoys.com/~eric
Hi!
Quoted 7 lines
Quoted 3 lines
But I guess swsusp is going to make this more "interesting" as progressbar is nice to have there, and userland can not help at that point.
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
Actually, it does work on most of UP/IDE machines by now. Remaining problems tend to be unsupported drivers. I can't help with devices I do not have, unfortunately, so there's little I can do.
I'm working on smp support just now... But some progress indication is must have in future - we had people going "ouch I thought it is stuck" when they in fact needed to wait 30seconds.
Pavel
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Pavel" == Pavel Machek <[email protected]> writes:
Pavel> Hi!
Quoted 7 lines
But I guess swsusp is going to make this more "interesting" as progressbar is nice to have there, and userland can not help at that point.
Quoted 4 lines
Personally I'd prefer the effort went into making suspend actually work on more machines rather than painting eyecandy for the minority of machines it currently works on.
Pavel> Actually, it does work on most of UP/IDE machines by now. Pavel> Remaining problems tend to be unsupported drivers. I can't help Pavel> with devices I do not have, unfortunately, so there's little I Pavel> can do.
[...]
Just to clarify -- in one of my previous posts I said that swsusp2 works very well for me. I meant *swsusp2*, not swsusp. It is unfortunate that the two projects are so similarly named. They are very different from the user perspective.
--J.
Quoted 3 lines · Christoph Hellwig
No. This stuff has no business in the kernel, paint your fancy graphics ontop of fbdev. And the SuSE bootsplash patch is utter crap, I mean what do you have to smoke to put a jpeg decoder into the kernel?
Well how are you going to be alble to watch pr0n att kernel boot without a jpeg decoder? :) The problem is that it's hard to have a X server running when suspending. An ascii progress bar could work.
Quoted 3 lines · Christoph Hellwig
No. This stuff has no business in the kernel, paint your fancy graphics ontop of fbdev. And the SuSE bootsplash patch is utter crap, I mean what do you have to smoke to put a jpeg decoder into the kernel?
Christoph, don't assume drugs just because you lack a little fantasy ;)
I agee with kernel 2.6 one could do a lot better due to proper initramfs handling, but in kernel 2.4 there was no decent way of placing userspace code early enough to be executed before framebuffer initialization.
On the other hand, the jpeg decoder is 8k object size - less than the dozens of gzip/gunzip algorithms in the kernel, so complaining sounds a little foolish to me. If you just want to bitch, go and critizise that with 1024x768 the bootsplash patch eats 1.5MB of memory permanently. THAT would make sense, if anything.
Whether one wants retro text messages or a graphical bootup mechanism is sure a philosophical thing. IMHO starting X that early is not an option.
Stefan
Quoted 3 lines · Stefan Reinauer
On the other hand, the jpeg decoder is 8k object size - less than the dozens of gzip/gunzip algorithms in the kernel, so complaining sounds a little foolish to me.
The zlibs should be consolidated these days, I remember an effort about 18 months back to do so at least. Did any new ones get introduced since then ?
Quoted 2 lines
Whether one wants retro text messages or a graphical bootup mechanism is sure a philosophical thing. IMHO starting X that early is not an option.
It works surprisingly well.
Dave
Quoted 2 lines · El Fri, 9 Jul 2004 16:48:59 +0200 Stefan Reinauer <[email protected]>…
Whether one wants retro text messages or a graphical bootup mechanism is sure a philosophical thing. IMHO starting X that early is not an option.
Is really neccesary to use a X server? Why not just modify the init scripts to use fbi to show a image? Is not that the kernel takes a lot of time to boot and run init - even windows XP shows an ascii bar while it loads their kernel, that period of time doesn't takes too much time and it doesn't annoy anyone. You could switch off the printk output too, so the users doesn't see any kernel message at all while init runs and the scripts puts the image in the framebuffer console.
Quoted 3 lines · Diego Calleja García
Is really neccesary to use a X server? Why not just modify the init scripts to use fbi to show a image? Is not that the kernel takes a lot of time to boot and run init - even windows XP shows an ascii bar while it loads their kernel,
So you know the internals of the NT kernel? That bar is probably just the bootloader loading the kernel from disk :).
Quoted 4 lines
that period of time doesn't takes too much time and it doesn't annoy anyone. You could switch off the printk output too, so the users doesn't see any kernel message at all while init runs and the scripts puts the image in the framebuffer console.
That is the "clean" approach, but what I wanted was something nice to look at while booting or suspending my laptop. Whether it be a retro ascii thingy or a fancy graphical thingy doesn't really matter.