Re: Suspend to RAM: help with whitelist wanted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux