Suspend to RAM: help with whitelist wanted

Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

On www.sf.net/projects/suspend , there's s2ram.c program for
suspending machines. It contains whitelist of known machines, along
with methods to get their video working (similar to
Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
fill in whitelist automatically, so I need your help.

I do not yet have solution for machines that need vbetool; fortunately
my machines do not need that :-), and it is pretty complex (includes
x86 emulator).

Routine I'd like you to modify looks like:

        if (!strcmp(sys_vendor, "IBM")) {
                if (!strcmp(sys_version, "ThinkPad X32")) {
                        machine_known();
                        set_acpi_video_mode(3);
                        radeon_backlight_off();
                        return;
                }
        }

... so it is pretty easy (but any patches are welcome).

								Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Luca]

Pavel Machek <pavel@suse.cz> ha scritto:
> Hi!
> 
> On www.sf.net/projects/suspend , there's s2ram.c program for
> suspending machines. It contains whitelist of known machines, along
> with methods to get their video working (similar to
> Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
> fill in whitelist automatically, so I need your help.
> 
> I do not yet have solution for machines that need vbetool; fortunately
> my machines do not need that :-), and it is pretty complex (includes
> x86 emulator).

What about adding something like:

void s2ram_restore(void) {
        if (needed)
                fork_and_exec(vbetool);
}

machine_table could set a global flag or something. It would be
possibile to us an array to carry the informations about what need to be
done on restore, i.e. something like:

void machine_table() {
        if ((!strcmp(sys_vendor, "ASUS")) {
                if (!strcmp(sys_version, "My notebook")) {
                        machine_known();
                        on_resume[NEED_VBETOOL] = 1;
                        return;
                }
        }
}

void s2ram_restore(void) {
        if (on_resume[NEED_VBETOOL])
                fork_and_exec(vbetool);
        if (on_resume[NEED_RADEON_STUFF])
                radeon_stuff();
        if (on_resume[NEED_FOOBAR])
                black_magic();
}

Ugly? Maybe, but you don't have to fiddle with a x86 emulator.

Luca
-- 
Home: http://kronoz.cjb.net
Windows NT: Designed for the Internet. The Internet: Designed for Unix.

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

On Pá 27-01-06 18:04:06, Luca wrote:
> Pavel Machek <pavel@suse.cz> ha scritto:
> > Hi!
> > 
> > On www.sf.net/projects/suspend , there's s2ram.c program for
> > suspending machines. It contains whitelist of known machines, along
> > with methods to get their video working (similar to
> > Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
> > fill in whitelist automatically, so I need your help.
> > 
> > I do not yet have solution for machines that need vbetool; fortunately
> > my machines do not need that :-), and it is pretty complex (includes
> > x86 emulator).
> 
> What about adding something like:
> 
> void s2ram_restore(void) {
>         if (needed)
>                 fork_and_exec(vbetool);
> }

Yes... that's what I wanted to avoid. ... ...

I originally wanted to avoid calling external problems. That way,
s2ram code could be pagelocked and you would get your video back even
in case of disk problems etc.

[I thought that it would bring problems with suspend-to-both; but I
was wrong, no such problem exists.]

> Ugly? Maybe, but you don't have to fiddle with a x86 emulator.

...and then there's a issue of how to do vbetool vbestate
save. According to docs it should be done just once, but that looks
pretty fragile to me. Perhaps we can just do it unconditionaly?

								Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Olivier Galibert]

On Sat, Jan 28, 2006 at 12:05:35AM +0100, Pavel Machek wrote:
> I originally wanted to avoid calling external problems. That way,
> s2ram code could be pagelocked and you would get your video back even
> in case of disk problems etc.

You should not add yet another program that does video card accesses
from userspace.  The xorg and fbdev developpers are having a hard
enough time already making sure both sides have a consistent view of
the video card state, and it looks like they're on the way to unifying
as much as they can in the kernel under drm just because of these
difficulties.  Do not add to them by frobbing the card in
unpredictable ways from userspace, please.

  OG.

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

On So 28-01-06 02:05:25, Olivier Galibert wrote:
> On Sat, Jan 28, 2006 at 12:05:35AM +0100, Pavel Machek wrote:
> > I originally wanted to avoid calling external problems. That way,
> > s2ram code could be pagelocked and you would get your video back even
> > in case of disk problems etc.
> 
> You should not add yet another program that does video card accesses
> from userspace.  The xorg and fbdev developpers are having a hard

There's no other solution, sorry. xorg are not even involved -- we do
it on text console. And unless you want x86 emulator in kernel, we
need something to restore our video in userspace.
								Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

> > On www.sf.net/projects/suspend , there's s2ram.c program for
> > suspending machines. It contains whitelist of known machines, along
> > with methods to get their video working (similar to
> > Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
> > fill in whitelist automatically, so I need your help.
> > 
> > I do not yet have solution for machines that need vbetool; fortunately
> > my machines do not need that :-), and it is pretty complex (includes
> > x86 emulator).
> 
> What about adding something like:
> 
> void s2ram_restore(void) {
>         if (needed)
>                 fork_and_exec(vbetool);
> }
> 
> machine_table could set a global flag or something. It would be
> possibile to us an array to carry the informations about what need to be
> done on restore, i.e. something like:

I can imagine fork_and_exec... Disadvantages are:

* if disk driver is toast, user does not see anything

* vbetool can be missing from the system, or wrong version, or
something like that.

Other solution is to just integrate vbetool into s2ram. Advantages
are:

* s2ram is nicely integrated.

Disadvantages are:

* code duplication.

If vbetool's primary purpose is to fix video after suspend/resume,
then perhaps right thing to do is to integrate it into s2ram and
maintain it there.

Matthew, what do you think?

Luca, would you cook quick&hacky fork-and-exec patch? I do not have
machine that needs vbetool...
							Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Matthew Garrett]

On Sat, Jan 28, 2006 at 12:22:07AM +0100, Pavel Machek wrote:

> If vbetool's primary purpose is to fix video after suspend/resume,
> then perhaps right thing to do is to integrate it into s2ram and
> maintain it there.

That's the primary purpose, though there's a couple of edge cases. 
For VBE state saving/restoring, it seems to be important to save the 
state before X has started rather than doing so at suspend time - some 
i855 systems break otherwise.

Not strictly related - Pavel, try taking a look at the acpi-support 
package in http://archive.ubuntu.com/ubuntu/pool/main/a/acpi-support/ . 
There's a large list of witelisted hardware there. OSDL recently set up 
a mailing list (desktop-portables@lists.osdl.org) for cross-distribution 
laptop discussion. It would probably be helpful to discuss working 
machines there, rather than duplicate the whitelisting efforts.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

> > If vbetool's primary purpose is to fix video after suspend/resume,
> > then perhaps right thing to do is to integrate it into s2ram and
> > maintain it there.
> 
> That's the primary purpose, though there's a couple of edge cases. 
> For VBE state saving/restoring, it seems to be important to save the 
> state before X has started rather than doing so at suspend time - some 
> i855 systems break otherwise.

Well, doing it at boot is slightly ugly; I'd like s2ram to just work,
and not need boot-time-hooks. [If there's no other solution... what
can I do, but I do not like it.]

> Not strictly related - Pavel, try taking a look at the acpi-support 
> package in http://archive.ubuntu.com/ubuntu/pool/main/a/acpi-support/ . 
> There's a large list of witelisted hardware there. OSDL recently set
> up 

Thanks for pointer! Anyway, AFAICT the list is not really adequate. It
lists working machines, but does not really list all the switches
neccessary to get the video working. (Well, it tries in some cases,
*strange*, perhaps less switches are neccessary than I think?)

> a mailing list (desktop-portables@lists.osdl.org) for cross-distribution 
> laptop discussion. It would probably be helpful to discuss working 
> machines there, rather than duplicate the whitelisting efforts.

I'm afraid I don't have a time for another mailing list, and this
should not be really related to the desktop...
							Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Matthew Garrett]

On Sat, Jan 28, 2006 at 09:42:25AM +0100, Pavel Machek wrote:

> Well, doing it at boot is slightly ugly; I'd like s2ram to just work,
> and not need boot-time-hooks. [If there's no other solution... what
> can I do, but I do not like it.]

Indeed. The symptoms are that X stops drawing the background to windows, 
and it seems to be very strongly tied to saving the state while X is 
running (even if X is not currently the foreground VT). 

> Thanks for pointer! Anyway, AFAICT the list is not really adequate. It
> lists working machines, but does not really list all the switches
> neccessary to get the video working. (Well, it tries in some cases,
> *strange*, perhaps less switches are neccessary than I think?)

For machines where nothing is listed, we do POSTing and restore the VBE 
state. These may not be necessary in all cases, but they don't seem to 
be actively harmful except on the machines where they're explicitly 
switched of.f
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

> > Thanks for pointer! Anyway, AFAICT the list is not really adequate. It
> > lists working machines, but does not really list all the switches
> > neccessary to get the video working. (Well, it tries in some cases,
> > *strange*, perhaps less switches are neccessary than I think?)
> 
> For machines where nothing is listed, we do POSTing and restore the VBE 
> state. These may not be necessary in all cases, but they don't seem to 
> be actively harmful except on the machines where they're explicitly 
> switched of.f

Ahha, nice. vbetool seems to work on very wide range of machines.
								Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Luca]

Il Sat, Jan 28, 2006 at 12:22:07AM +0100, Pavel Machek ha scritto: 
> > > On www.sf.net/projects/suspend , there's s2ram.c program for
> > > suspending machines. It contains whitelist of known machines, along
> > > with methods to get their video working (similar to
> > > Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
> > > fill in whitelist automatically, so I need your help.
> > > 
> > > I do not yet have solution for machines that need vbetool; fortunately
> > > my machines do not need that :-), and it is pretty complex (includes
> > > x86 emulator).
> > 
> > What about adding something like:
> > 
> > void s2ram_restore(void) {
> >         if (needed)
> >                 fork_and_exec(vbetool);
> > }
> > 
> > machine_table could set a global flag or something. It would be
> > possibile to us an array to carry the informations about what need to be
> > done on restore, i.e. something like:
> 
> I can imagine fork_and_exec... Disadvantages are:
> 
> * if disk driver is toast, user does not see anything
> 
> * vbetool can be missing from the system, or wrong version, or
> something like that.
> 
> Other solution is to just integrate vbetool into s2ram. Advantages
> are:
> 
> * s2ram is nicely integrated.
> 
> Disadvantages are:
> 
> * code duplication.
> 
> If vbetool's primary purpose is to fix video after suspend/resume,
> then perhaps right thing to do is to integrate it into s2ram and
> maintain it there.
> 
> Matthew, what do you think?
> 
> Luca, would you cook quick&hacky fork-and-exec patch? I do not have
> machine that needs vbetool...

Very quick and very hacky ;)

The following patch works on my notebook. A few notes about it:

- I must stop acpid before suspending otherwise it will get a "power
  button pressed" event on resume and shutdown the machine; not related
  to s2ram though.
- vbetool manpage says that it must be invoked from a text console;
  since it works from X on my system I never bothered to do a chvt from
  my suspend script.
- I always save state before suspend since sometimes I STR from X,
  sometimes from the console and the state file generated by vbetool is
  different. According to Matthew Garrett this will break on some
  setups... if state needs to the saved before X is started then I guess
  that we need an init script that dump the state in a known place; even
  if you integrate vbetool into s2ram it will need the state file, so if
  the disk doesn't come back to life you're screwed...

--- suspend/s2ram.c	2006-01-28 13:59:41.000000000 +0100
+++ suspend/s2ram.c	2006-01-28 14:19:37.000000000 +0100
@@ -15,2 +15,4 @@ int test_mode;
 
+static int need_vbetool;
+
 static void machine_known(void)
@@ -49,2 +51,9 @@ static void machine_table(void)
 	}
+	if (!strcmp(sys_vendor, "ASUSTEK ")) {
+		if (!strcmp(sys_product, "L3000D")) {
+			machine_known();
+			need_vbetool = 1;
+			return;
+		}
+	}
 
@@ -59,2 +68,30 @@ static void machine_table(void)
 
+static int vbe_state_save() {
+	int err;
+	
+	err = system("vbetool vbestate save > /tmp/.vbe.state");
+	if (err)
+		printf("vbetool failed to save video state with error %d\n.", err);
+
+	return err;
+}
+
+static int vbe_state_restore() {
+	int err;
+
+	err = system("vbetool post");
+	if (err) {
+		printf("vbetool failed to POST video board with error %d.\n", err);
+		return err;
+	}
+	
+	err = system("vbetool vbestate restore < /tmp/.vbe.state");
+	if (err)
+		printf("vbetool failed to restore video state with error %d.\n", err);
+
+	remove("/tmp/.vbe.state");
+	
+	return err;
+}
+
 /* Code that can only be run on non-frozen system. It does not matter now
@@ -66,2 +103,5 @@ void s2ram_prepare(void)
 	machine_table();
+	if (need_vbetool)
+		if (vbe_state_save())
+			exit(1);
 }
@@ -81,2 +121,7 @@ void s2ram_do(void)
 
+void s2ram_resume(void) {
+	if (need_vbetool)
+		vbe_state_restore();
+}
+
 int main(int argc, char *argv[])
@@ -103,2 +148,3 @@ int main(int argc, char *argv[])
 	s2ram_do();
+	s2ram_resume();
 	return 0;


Luca
-- 
Home: http://kronoz.cjb.net
"Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
 chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi" 
Sun Tzu -- L'arte della guerra

Re: Suspend to RAM: help with whitelist wanted

[Jan De Luyck]

On Saturday 28 January 2006 16:58, Luca wrote:
> - I must stop acpid before suspending otherwise it will get a "power
>   button pressed" event on resume and shutdown the machine; not related
>   to s2ram though.

You can fix that by e.g creating a file /tmp/acpi_sleep, and checking in the 
powerbutton routine if the file is present. Delete it if it is present, and 
just shutdown the machine if not. 

I have to do that too on my Acer TM803.

-- 
If this were Ada, I suppose we'd just constant fold 1/0 into

    die "Illegal division by zero"
		-- Larry Wall in <199711100226.SAA12549@wall.org>

Re: Suspend to RAM: help with whitelist wanted

[Luca]

Il Sat, Jan 28, 2006 at 05:04:18PM +0100, Jan De Luyck ha scritto: 
> On Saturday 28 January 2006 16:58, Luca wrote:
> > - I must stop acpid before suspending otherwise it will get a "power
> >   button pressed" event on resume and shutdown the machine; not related
> >   to s2ram though.
> 
> You can fix that by e.g creating a file /tmp/acpi_sleep, and checking in the 
> powerbutton routine if the file is present. Delete it if it is present, and 
> just shutdown the machine if not. 
> 
> I have to do that too on my Acer TM803.

Well this is not a big deal, my suspend script just does:

/etc/init.d/acpid stop
echo mem > /sys/power/state
/etc/init.d/acpid start

Luca
-- 
Home: http://kronoz.cjb.net
La vasca da bagno fu inventata nel 1850, il telefono nel 1875.
Se fossi vissuto nel 1850, avrei potuto restare in vasca per 25 anni
senza sentir squillare il telefono

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

> > > void s2ram_restore(void) {
> > >         if (needed)
> > >                 fork_and_exec(vbetool);
> > > }
> > > 
> > > machine_table could set a global flag or something. It would be
> > > possibile to us an array to carry the informations about what need to be
> > > done on restore, i.e. something like:
> > 
> > I can imagine fork_and_exec... Disadvantages are:
> > 
> > * if disk driver is toast, user does not see anything
> > 
> > * vbetool can be missing from the system, or wrong version, or
> > something like that.
> > 
> > Other solution is to just integrate vbetool into s2ram. Advantages
> > are:
> > 
> > * s2ram is nicely integrated.
> > 
> > Disadvantages are:
> > 
> > * code duplication.
> > 
> > If vbetool's primary purpose is to fix video after suspend/resume,
> > then perhaps right thing to do is to integrate it into s2ram and
> > maintain it there.
> > 
> > Matthew, what do you think?
> > 
> > Luca, would you cook quick&hacky fork-and-exec patch? I do not have
> > machine that needs vbetool...
> 
> Very quick and very hacky ;)
> 
> The following patch works on my notebook. A few notes about it:
> 
> - I must stop acpid before suspending otherwise it will get a "power
>   button pressed" event on resume and shutdown the machine; not related
>   to s2ram though.

I work around this one by pressing lid button to wake the machine up.

> - vbetool manpage says that it must be invoked from a text console;
>   since it works from X on my system I never bothered to do a chvt from
>   my suspend script.
> - I always save state before suspend since sometimes I STR from X,
>   sometimes from the console and the state file generated by vbetool is
>   different. According to Matthew Garrett this will break on some
>   setups... if state needs to the saved before X is started then I guess
>   that we need an init script that dump the state in a known place; even
>   if you integrate vbetool into s2ram it will need the state file, so if
>   the disk doesn't come back to life you're screwed...

No, I'm not... I'd just load state file into memory before even
starting suspend :-).

Thanks for the patch!
							Pavel

> --- suspend/s2ram.c	2006-01-28 13:59:41.000000000 +0100
> +++ suspend/s2ram.c	2006-01-28 14:19:37.000000000 +0100
> @@ -15,2 +15,4 @@ int test_mode;
>  
> +static int need_vbetool;
> +
>  static void machine_known(void)
> @@ -49,2 +51,9 @@ static void machine_table(void)
>  	}
> +	if (!strcmp(sys_vendor, "ASUSTEK ")) {
> +		if (!strcmp(sys_product, "L3000D")) {
> +			machine_known();
> +			need_vbetool = 1;
> +			return;
> +		}
> +	}
>  
> @@ -59,2 +68,30 @@ static void machine_table(void)
>  
> +static int vbe_state_save() {
> +	int err;
> +	
> +	err = system("vbetool vbestate save > /tmp/.vbe.state");
> +	if (err)
> +		printf("vbetool failed to save video state with error %d\n.", err);
> +
> +	return err;
> +}
> +
> +static int vbe_state_restore() {
> +	int err;
> +
> +	err = system("vbetool post");
> +	if (err) {
> +		printf("vbetool failed to POST video board with error %d.\n", err);
> +		return err;
> +	}
> +	
> +	err = system("vbetool vbestate restore < /tmp/.vbe.state");
> +	if (err)
> +		printf("vbetool failed to restore video state with error %d.\n", err);
> +
> +	remove("/tmp/.vbe.state");
> +	
> +	return err;
> +}
> +
>  /* Code that can only be run on non-frozen system. It does not matter now
> @@ -66,2 +103,5 @@ void s2ram_prepare(void)
>  	machine_table();
> +	if (need_vbetool)
> +		if (vbe_state_save())
> +			exit(1);
>  }
> @@ -81,2 +121,7 @@ void s2ram_do(void)
>  
> +void s2ram_resume(void) {
> +	if (need_vbetool)
> +		vbe_state_restore();
> +}
> +
>  int main(int argc, char *argv[])
> @@ -103,2 +148,3 @@ int main(int argc, char *argv[])
>  	s2ram_do();
> +	s2ram_resume();
>  	return 0;
> 
> 
> Luca

-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Pavel Machek]

Hi!

> > If vbetool's primary purpose is to fix video after suspend/resume,
> > then perhaps right thing to do is to integrate it into s2ram and
> > maintain it there.
> > 
> > Matthew, what do you think?
> > 
> > Luca, would you cook quick&hacky fork-and-exec patch? I do not have
> > machine that needs vbetool...
> 
> Very quick and very hacky ;)

Thanks; applied after some cleanups. Could you fetch it from cvs and
confirm it still works?
								Pavel
-- 
Thanks, Sharp!

Re: Suspend to RAM: help with whitelist wanted

[Luca]

Il Sat, Jan 28, 2006 at 05:36:11PM +0100, Pavel Machek ha scritto: 
> > > If vbetool's primary purpose is to fix video after suspend/resume,
> > > then perhaps right thing to do is to integrate it into s2ram and
> > > maintain it there.
> > > 
> > > Matthew, what do you think?
> > > 
> > > Luca, would you cook quick&hacky fork-and-exec patch? I do not have
> > > machine that needs vbetool...
> > 
> > Very quick and very hacky ;)
> 
> Thanks; applied after some cleanups. Could you fetch it from cvs and
> confirm it still works?

Yup, it's ok.

Luca
-- 
Home: http://kronoz.cjb.net
The trouble with computers is that they do what you tell them, 
not what you want.
D. Cohen