Re: [Suspend-devel] [PATCH] Enable splash setting via command-line

2007-08-15 Thread Tim Dijkstra
On Wed, 15 Aug 2007 19:30:27 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Saturday, 4 August 2007 23:17, Alon Bar-Lev wrote:
> > 
> > Hello,
> > 
> > This patch adds --splash argument to s2both, s2disk, resume.
> > It is required especially for resume when you want to disable splash in 
> > initramfs
> > as result of kernel parameter, even if it usually turned on on suspend.conf 
> > you
> > wish to turn it off.
> > 
> > This is handy if you get oops or cannot boot and see no messages.
> 
> I have no opinion.

Seems fine to me.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] vt switch during image write

2007-08-08 Thread Tim Dijkstra
On Tue, 7 Aug 2007 01:50:12 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:


> The question is: Why cannot I switch from one vt to another during image 
> write?
> I guess some lock out somewhere at freeze something...
> I will be glad to be able to switch from silent to verbose modes
> during image write.

At some point I added an explicit lock against switching VTs at some
point. IIRC, this is to be sure we save a consistent state.
 
> Also, and unrelated, using radeonfb, during snapshot the screen goes
> black, and returns after a few seconds... This is kernel related...
> Maybe there is a way to tell the framebuffer not to blackout?

I guess this is when freeze is called. I think this is with all fb
(although here it isn't seconds) I think it has something to do with
telling all devices to prepare for suspend or so... but Rafael probably
knows more about that.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH 6/6] - autoconf/automake glue - s2ram

2007-08-04 Thread Tim Dijkstra
On Fri, 3 Aug 2007 13:45:20 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> > 1. Move main() out of s2ram.c into s2ram-main.c, this will enable s2ram.o 
> > to be included
> > in both s2ram and s2both without recompilation.

That way we get even more s2ram-* files. In s2ram.c there would not be
much left; only one function of only a few lines. Can't you do that
differently?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH 6/6] - autoconf/automake glue - s2ram

2007-08-04 Thread Tim Dijkstra
On Fri, 3 Aug 2007 13:45:20 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> > 2. Split whitelist.c into whitelist.h/whitelist.c as including .c is none 
> > standard/unsupported.  
> 
> These changes have to be looked at by Pavel and Stefan.

At some point I suggested this too. Pavel was somewhat against it, and
do not really remember the argument though.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Set cpufreq to max during suspend/resume

2007-07-22 Thread Tim Dijkstra
On Sun, 22 Jul 2007 07:46:40 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:

> On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > No. The vbetool code is linked in. It doesn't run as regular processes.
> > At the time we do those hacks, we are the only not-frozen part of userspace.
> > This is what makes it different from running it from a bunch of scripts.
> 
> Are you sure?
> Can you please refer me to the relevant lines in the code?

Look at suspend.c

At 1448 we run some hacks before the suspend. A few lines later we call
suspend_system, in that function at 761 we freeze userspace. Then at
line 807 we suspend to ram. If that call returns we're back from
suspend. At 812 we call some more hacks with userspace still frozen,
only after that we jump to Unfreeze.

These s2ram_* funcs in the end call code from vbetool/vbetool.c which
is indeed linked in. But partly I remembered it wrongly. The hacks
_before_ suspend are called with an unfrozen userspace, those after on
a frozen userspace.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Set cpufreq to max during suspend/resume

2007-07-21 Thread Tim Dijkstra
On Sat, 21 Jul 2007 23:08:30 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:

> On 7/21/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> > On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > > Right. So if we start putting things like cpufreq in the suspend package,
> > > we would have an argumentation to put everything which is in pm-utils, the
> > > hibernate script etc. to it. And I don't think this is what we want.
> >
> > You can put vbetool, radeontool, whitelist etc in pm-utils too...
> > reducing the suspend/resume dependencies...
> > hibernate-script already doing this.
> 
> Don't get me wrong...
> I would not be offended if this not accepted... :)
> It is just that I think the other hacks should also be removed... as
> for my understanding they are running as regular process... So that
> the question of early/late is irrelevant, the same functionality can
> be handled by hibernate-script or this pm-utils.

No. The vbetool code is linked in. It doesn't run as regular processes.
At the time we do those hacks, we are the only not-frozen part of userspace.
This is what makes it different from running it from a bunch of scripts. 

One of the philosophies behind uswsusp is that saving pci states,
vbemodes, etc, is something we should do in a way where we can't be
interfered by userspace processes. This means at late as possible in
the suspend process, when userspace is frozen.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Set cpufreq to max during suspend/resume

2007-07-21 Thread Tim Dijkstra
On Sat, 21 Jul 2007 18:28:24 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:

> On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > This is already done in pm-utils. Upstream uses 'userspace' as governor,
> > which I personally think is wrong. openSUSE uses the 'performance'
> > governor and this only because of a bug in the kernel which caused the
> > system to hang on suspend AFAIR.
> 
> You can also do the whitelist, vbetool, radeontool, pci etc...
> 
> Someone needs to draw the line... :)

Those video utilities have to be called as close to the actual resume
as possible. For setting cpufreq this isn't so important.

> And please remember that referencing to a specific distribution
> project/functionality is like preferring your group of users over the
> other...

He has @suse in the address, and such can't help it;)

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Set cpufreq to max during suspend/resume

2007-07-20 Thread Tim Dijkstra
On Fri, 20 Jul 2007 22:20:51 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> > Yet another patch in the suspend2 feature-set series.
> > It sets cpufreq to maximum during the cycle.

I haven't looked at the patch, but this doesn't really sound essential
for uswsusp. Maybe it should go into pm-utils or similar.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Fw: Bug#392168: Resume device on external USB drive causes the boot process to stop

2007-06-18 Thread Tim Dijkstra
Hi,

What do people think about this?
--- Begin Message ---
I have an old system (eMachine 433MH) with a new external USB drive
(which is actually faster than the internal hard drive that came with
the box).  It takes a few seconds for the Linux to bring it online, due
in some part I think to a 5 second delay in kernel driver usb-storage
(specifically usb.c).  This console message gives a clue as to what is
happening:

usb-storage: waiting for device to settle before scanning
  
Once I installed uswsusp I noticed the boot process stopping because the
'stat' call only happens once (and fails), but almost immediately
afterward the drive would come online.

I worked up a patch that issues the stat call, sleeps for half a second
then checks again.  If it's successful it breaks out of the loop.  I set
the loop counter to 60 for a 30 second timeout.  It takes about 5 to 10
seconds for the drive to come online on my system but again, my system
is slow, mileage may vary.  Here's the patch:

--- resume.c.dpkg   2007-06-10 22:49:25.0 -0400
+++ resume.c2007-06-11 23:02:33.0 -0400
@@ -731,6 +731,9 @@
struct stat stat_buf;
int dev;
int n, error = 0;
+   // Grace period variables
+   int loopcnt;
+   unsigned int usecs = 50;// half a second

page_size = getpagesize();
buffer_size = BUFFER_PAGES * page_size;
@@ -755,6 +758,18 @@
if (splash_param != 'y' && splash_param != 'Y')
splash_param = 0;

+   /*
+*  30 second grace period to allow resume device
+*  to come online (i.e. external USB drives)
+   */
+   for (loopcnt = 1; loopcnt <= 60; loopcnt++)
+   {
+   if (stat(resume_dev_name, &stat_buf) != 0)
+   usleep(usecs);  // wait a half
second
+   else
+   break;
+   }
+
while (stat(resume_dev_name, &stat_buf)) {
fprintf(stderr,
"resume: Could not stat the resume device
file.\n"

  


--- End Message ---


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Patch, make s2ram --test return exit status.

2007-06-17 Thread Tim Dijkstra
On Fri, 8 Jun 2007 13:56:25 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 07, 2007 at 10:51:38PM +0200, Tim Dijkstra wrote:
> > Hi,
> > 
> > I thought it was useful to be able to get the exit status from s2ram --test.
> 
> Yes, sounds sane. Maybe we should return "failure" for those UNSURE entries?
> (i like to get rid of them, but giving people incentive to report while still
> not directly breaking their setup might be a good idea :-)

That is fine with me. This would mean for debian that from hal a
machine with an unsure entry now refuses to suspend. 

I'll commit the patch now.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Patch, make s2ram --test return exit status.

2007-06-07 Thread Tim Dijkstra
Hi,

I thought it was useful to be able to get the exit status from s2ram --test.

grts Tim


Index: s2ram-ppc.c
===
RCS file: /cvsroot/suspend/suspend/s2ram-ppc.c,v
retrieving revision 1.1
diff -u -r1.1 s2ram-ppc.c
--- s2ram-ppc.c 13 May 2007 20:16:53 -  1.1
+++ s2ram-ppc.c 7 Jun 2007 20:49:11 -
@@ -39,9 +39,10 @@
printf("We don't have quirks and hence no whitelist on powerpc\n");
 }
 
-void machine_known(void)
+int machine_known(void)
 {
printf("We don't have quirks and hence no whitelist on powerpc\n");
+   return 0;
 }
 
 int s2ram_hacks(void)
Index: s2ram-x86.c
===
RCS file: /cvsroot/suspend/suspend/s2ram-x86.c,v
retrieving revision 1.4
diff -u -r1.4 s2ram-x86.c
--- s2ram-x86.c 1 Jun 2007 10:27:50 -   1.4
+++ s2ram-x86.c 7 Jun 2007 20:49:11 -
@@ -137,12 +137,13 @@
return ret;
 }
 
-void machine_known(void)
+int machine_known(void)
 {
int i = machine_match();
if (i < 0) {
printf("Machine unknown\n");
identify_machine();
+   return 1;
}
 
s2ram_check(i);
@@ -168,6 +169,7 @@
 * the one we already have (additional BIOS version e.g)...
 */
identify_machine();
+   return 0;
 }
 
 int find_vga(void)
Index: s2ram.c
===
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.57
diff -u -r1.57 s2ram.c
--- s2ram.c 13 May 2007 20:16:53 -  1.57
+++ s2ram.c 7 Jun 2007 20:49:11 -
@@ -74,8 +74,8 @@
identify_machine();
exit(0);
case 'n':
-   machine_known();
-   exit(0);
+   ret = machine_known();
+   exit(ret);
case '?':
usage("s2ram", options, optstring);
exit(1);
Index: s2ram.h
===
RCS file: /cvsroot/suspend/suspend/s2ram.h,v
retrieving revision 1.9
diff -u -r1.9 s2ram.h
--- s2ram.h 13 May 2007 20:10:16 -  1.9
+++ s2ram.h 7 Jun 2007 20:49:11 -
@@ -19,7 +19,7 @@
 int s2ram_hacks(void);
 int s2ram_is_supported(void);
 void identify_machine(void);
-void machine_known(void);
+int machine_known(void);
 int s2ram_do(void);
 int s2ram_generic_do(void);
 void s2ram_resume(void);


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [Patch] fix "s2ram -n" / be a bit more explicit wrt. UNSURE

2007-05-31 Thread Tim Dijkstra
On Thu, 31 May 2007 18:24:43 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> the first hunk fixes s2ram -n, without it does not print what hacks would
> actually be applied.
> 
> The other hunks let s2ram complain louder about machines that are still
> UNSURE. The fedora guys made pretty bad experiences with entries marked
> UNSURE and we actually seldom get reports to confirm those, since s2ram
> is quite silent about this flag. I changed that. Now it also complains
> during a plain "s2ram" call, even though it will probably just work.
> 
> I will need to move s2ram_check() before machine_known() to fix the
> "implicit declaration"-warning, but i'll do that separately to not
> obfuscate the patch.
> 
> Any objections?

Nope

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] swap-offset is using a deprecated SCSI ioctl

2007-05-20 Thread Tim Dijkstra
Hi Luca,

I just got this report from a swap-offset user:

  I've just stumbled upon this message in my syslog after today's upgrade of 
uswsusp:

  program swap-offset is using a deprecated SCSI ioctl, please convert it to 
SG_IO

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2ram broken for Linux 2.6.22, libx86 broken on x86-64

2007-05-20 Thread Tim Dijkstra
On Sun, 20 May 2007 21:02:23 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Sunday, 20 May 2007 20:31, Tim Dijkstra wrote:
> > On Sun, 20 May 2007 15:27:18 +0200
> > Stefan Richter <[EMAIL PROTECTED]> wrote:
> > 
> > > Rafael wrote:
> > >
> > > > Actually, on x86-64 you have to compile it with
> > > 
> > > > $ make BACKEND=x86emu
> > 
> > > > Seife, perhaps we should add this information to README?  
> > 
> > It is already clearly documented in the HOWTO.
> 
> But HOWTO is for the suspend to disk.  It has "suspend to disk" in the title,
> so I wouldn't expect s2ram-only users to read it.  If something special is
> needed for s2ram, it should be documented in README.

But why should the README be for s2ram? It is all in the same
tarball... Maybe we should change the title of the HOWTO.

> > > Yes please, or add some "uname -m | grep x86_64" automatism.
> > > (Maybe I get bored next week and send something.  Unlikely though.)
> > 
> > We agreed to not have libx86 in our cvs anymore. We do not maintain it
> > nor develop it. With did a small poll back then; most distros had it
> > packaged already.
> 
> Not available in OpenSUSE 10.2 (or I don't know which package it's in), not
> available in Gentoo, apparently.  Fedora, anyone?

IIRC, stefan said it was in SUSE (but maybe that is not opensuse?).

> > So maybe you can package it for gentoo so other people can benefit from it.
> 
> Please be nice to our guests. ;-)

Sorry, I apologize:) But packaging would be a good thing to do. I do
not know how gentoo works though, never touched it.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2ram broken for Linux 2.6.22, libx86 broken on x86-64

2007-05-20 Thread Tim Dijkstra
On Sun, 20 May 2007 15:27:18 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:

> Rafael wrote:
>
> > Actually, on x86-64 you have to compile it with
> 
> > $ make BACKEND=x86emu

> > Seife, perhaps we should add this information to README?  

It is already clearly documented in the HOWTO.

> Yes please, or add some "uname -m | grep x86_64" automatism.
> (Maybe I get bored next week and send something.  Unlikely though.)

We agreed to not have libx86 in our cvs anymore. We do not maintain it
nor develop it. With did a small poll back then; most distros had it
packaged already. So maybe you can package it for gentoo so other
people can benefit from it.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2ram works s2both doesn't

2007-05-17 Thread Tim Dijkstra
On Thu, 17 May 2007 11:59:37 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Thursday, 17 May 2007 00:14, Tim Dijkstra wrote:
> > Hi,
> > 
> > I've got an report of a laptop that works with 
> > s2ram --vbe_save --vbe_post
> > 
> > But doesn't for s2both with the same options.
> > 
> > What does work however is
> > s2both -a 1
> > 
> > Somehow the difference in code path in s2both is significant from that of
> > s2ram (which basically does echo mem > /sys/..)
> > 
> > Any ideas how to fix this?
> 
> I'd try with 'shutdown method = shutdown', but that need not help.

But that wouldn't help for s2both going into S3, would it?
 
> We first have to make the kernel use ACPI control methods in accordance with
> the specification, but that will take time.

Hmm, OK. So you do have an idea what is causing this? And working on it?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2ram works s2both doesn't

2007-05-16 Thread Tim Dijkstra
Hi,

I've got an report of a laptop that works with 
s2ram --vbe_save --vbe_post

But doesn't for s2both with the same options.

What does work however is
s2both -a 1

Somehow the difference in code path in s2both is significant from that of
s2ram (which basically does echo mem > /sys/..)

Any ideas how to fix this?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] x86_64

2007-05-15 Thread Tim Dijkstra
On Tue, 15 May 2007 12:55:04 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Tuesday, 15 May 2007 08:40, Arkadiusz Miskiewicz wrote:
> > 
> > Makefile:
> > 1.57 (tdykstra 13-May-07): ARCH := $(shell uname -m | sed -e 
> > s/i.86/x86/ -e s/ppc.*/ppc/)
> > 
> > x86_64 not supported? Suspend builds (after fixing above) on x86_64 but no 
> > idea if works.
> 
> Supported.  I've been using it since the very beginning on x86_64.
> 
> The above Makefile bug seems to be recent.

Yes as you can see from the quote, from 13th of may. It was the patch from
luca that I applied, but I know, that is no excuse;)

Will fix it now.

grts Tim



signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Bug in option handling

2007-05-14 Thread Tim Dijkstra
On Sun, 13 May 2007 22:52:37 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Saturday, 12 May 2007 22:18, Tim Dijkstra wrote:
> > Hi,
> > 
> > OK, it turns out that my last patch for adding comments to usage had a
> > horrible bug. Although (struct option_descr) would yield a (struct option), 
> > as anticipated, the increment of the pointers of these structs ofcourse
> > wouldn't...
> > 
> > Anyway the patch below fixes this, although also in a bit hackish way.
> > usage() expects an \0 in the option.name string, and after that a comment.
> > Like this:
> > 
> >"help\0this text"
> 
> Hmm, couldn't we use a separate array of strings for that?

Yes, but I thought this was nice and compact;)

Anyway, after Pavel's OK, I committed it. I can change it of course if
you insist...

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Bug in option handling

2007-05-12 Thread Tim Dijkstra
Hi,

OK, it turns out that my last patch for adding comments to usage had a
horrible bug. Although (struct option_descr) would yield a (struct option), 
as anticipated, the increment of the pointers of these structs ofcourse
wouldn't...

Anyway the patch below fixes this, although also in a bit hackish way.
usage() expects an \0 in the option.name string, and after that a comment.
Like this:

   "help\0this text"

grts Tim

Index: config.c
===
RCS file: /cvsroot/suspend/suspend/config.c,v
retrieving revision 1.9
diff -u -r1.9 config.c
--- config.c2 May 2007 20:55:43 -   1.9
+++ config.c12 May 2007 20:10:37 -
@@ -104,23 +104,27 @@
return error;
 }
 
-void usage(char *my_name, struct option_descr *options, const char 
*short_options)
+/* We're abusing struct option a bit. usage() expects an \0 in the
+ * name string, and after that a comment.
+ */
+void usage(char *my_name, struct option *options, const char *short_options)
 {
-   struct option_descr *opt;
+   struct option *opt;
 
printf("Usage: %s [options]", my_name);
-   for (opt = options; opt->o.name; opt++) 
+   for (opt = options; opt->name; opt++) 
{
-   if (strchr(short_options,opt->o.val))
-   printf("\n  -%c, --%s", opt->o.val, opt->o.name);
+   const char *descr = opt->name + strlen(opt->name) + 1;
+   if (strchr(short_options,opt->val))
+   printf("\n  -%c, --%s", opt->val, opt->name);
else
-   printf("\n  --%s", opt->o.name);
+   printf("\n  --%s", opt->name);
 
-   if (opt->o.has_arg)
-   printf(" <%s>", opt->o.name);
+   if (opt->has_arg)
+   printf(" <%s>", opt->name);
 
-   if (strlen(opt->descr))
-   printf("\t%s",opt->descr);
+   if (strlen(descr))
+   printf("\t%s",descr);
}
 
printf("\n");
Index: config.h
===
RCS file: /cvsroot/suspend/suspend/config.h,v
retrieving revision 1.6
diff -u -r1.6 config.h
--- config.h2 May 2007 20:55:43 -   1.6
+++ config.h12 May 2007 20:10:37 -
@@ -21,13 +21,8 @@
unsigned int len;
 };
 
-struct option_descr {
-   struct option o;
-   const char *descr;
-};
-
 int parse(char *my_name, char *file_name, int parc, struct config_par *parv);
 
-void usage(char *my_name, struct option_descr options[], const char 
*short_options);
+void usage(char *my_name, struct option options[], const char *short_options);
 
 #define CONFIG_FILE"/etc/suspend.conf"
Index: resume.c
===
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.43
diff -u -r1.43 resume.c
--- resume.c2 May 2007 20:55:43 -   1.43
+++ resume.c12 May 2007 20:10:37 -
@@ -735,16 +735,24 @@
 /* Parse the command line and/or configuration file */
 static inline int get_config(int argc, char *argv[])
 {
-   static struct option_descr options[] = {
-   {   { "help",   no_argument,NULL, 'h'},
-   "\t\t\tthis text." },
-   {   { "config", required_argument,  NULL, 'f'},
-   "\t\talternative configuration file." },
-   {   { "resume_device",  required_argument,  NULL, 'r'},
-   "device that contains swap area"},
-   {   { "resume_offset",  required_argument,  NULL, 'o'},
-   "offset of swap file in resume device."},
-   {   { NULL, 0,  NULL,  0 }, ""}
+   static struct option options[] = {
+  { 
+  "help\0\t\t\tthis text",
+  no_argument, NULL, 'h'
+  },
+  { 
+  "config\0\t\talternative configuration file.",
+  required_argument,   NULL, 'f'
+  },
+  { 
+  "resume_device\0device that contains swap area", 
+  required_argument,   NULL, 'r'
+  },
+  { 
+  "resume_offset\0offset of swap file in resume device.",  
+  required_argument,   NULL, 'o'
+  },
+  { NULL,  0,  NULL,  0 }
};
int i, error;
char *conf_name = CONFIG_FILE;
@@ -754,7 +762,7 @@
char *rdev = NULL;
const char *optstring = "hf:o:r:";
 
-   while ((i = getopt_long(argc, argv, optstring, (struct option 
*)options, NULL)) != -1) {
+   while ((i = getopt_long(argc, argv, optstring, options, NULL)) != -1) {
 

Re: [Suspend-devel] Splashy features

2007-05-11 Thread Tim Dijkstra
On Thu, 10 May 2007 22:17:29 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> > -   } else if (!splashy_open()) {
> > +   } else if (!(error = splashy_open(mode))) {  
> 
> I'd prefer
> 
>   error = error = splashy_open(mode);
>   if (error) {
> 
> and analogously below.

huh?

Why is that?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Splashy features

2007-05-10 Thread Tim Dijkstra
Hi,

libsplashy changed the ABI a bit, needed to change something. It also
would want to know if we're suspend of resuming, it can then show a
penguin going to bed or waking up. 

Index: resume.c
===
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.43
diff -u -r1.43 resume.c
--- resume.c2 May 2007 20:55:43 -   1.43
+++ resume.c10 May 2007 20:01:14 -
@@ -806,6 +806,8 @@
 
if (splash_param != 'y' && splash_param != 'Y')
splash_param = 0;
+   else
+   splash_param = SPL_RESUME;
 
page_size = getpagesize();
buffer_size = BUFFER_PAGES * page_size;
Index: splash.c
===
RCS file: /cvsroot/suspend/suspend/splash.c,v
retrieving revision 1.6
diff -u -r1.6 splash.c
--- splash.c18 Jan 2007 23:23:22 -  1.6
+++ splash.c10 May 2007 20:01:14 -
@@ -11,13 +11,13 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "splash.h"
 #include "bootsplash.h"
 #include "splashy_funcs.h"
 #include "encrypt.h"
-#include 
-#include 
 
 /**
  * dummy functions in case if no splash system was found or
@@ -66,7 +66,7 @@
 }
 
 /* Tries to find a splash system and initializes interface functions */
-void splash_prepare(struct splash *splash, int enabled)
+void splash_prepare(struct splash *splash, int mode)
 {
int error = 0;
 
@@ -82,7 +82,7 @@
splash->prepare_abort   = prepare_abort;
splash->restore_abort   = restore_abort;
splash->key_pressed = key_pressed;
-   if (!enabled)
+   if (!mode)
return;
 
printf("Looking for splash system... ");
@@ -94,11 +94,14 @@
splash->dialog  = bootsplash_dialog;
splash->read_password = bootsplash_read_password;
 #ifdef CONFIG_SPLASHY
-   } else if (!splashy_open()) {
+   } else if (!(error = splashy_open(mode))) {
splash->finish  = splashy_finish;
splash->progress= splashy_progress;
splash->dialog  = splashy_dialog;
splash->read_password   = splashy_read_password;
+   splash->prepare_abort   = splashy_prepare_abort;
+   splash->restore_abort   = splashy_restore_abort;
+   splash->key_pressed = splashy_key_pressed;
 #endif
} else if (0) {
/* add another splash system here */
Index: splash.h
===
RCS file: /cvsroot/suspend/suspend/splash.h,v
retrieving revision 1.4
diff -u -r1.4 splash.h
--- splash.h10 Jan 2007 14:16:45 -  1.4
+++ splash.h10 May 2007 20:01:14 -
@@ -12,6 +12,9 @@
 #ifndef SPLASH_H
 #define SPLASH_H
 
+#define SPL_SUSPEND 1
+#define SPL_RESUME 2
+
 #include 
 
 /* generic interface functions for an arbitary splash method */
@@ -26,6 +29,6 @@
void (*restore_abort) (struct termios *);
 };
 
-void splash_prepare(struct splash *splash, int enabled);
+void splash_prepare(struct splash *splash, int mode);
 
 #endif /* SPLASH_H */
Index: splashy_funcs.c
===
RCS file: /cvsroot/suspend/suspend/splashy_funcs.c,v
retrieving revision 1.3
diff -u -r1.3 splashy_funcs.c
--- splashy_funcs.c 20 Sep 2006 14:15:50 -  1.3
+++ splashy_funcs.c 10 May 2007 20:01:14 -
@@ -13,20 +13,27 @@
 #include 
 
 #include 
+#include "splash.h"
 
 #include "encrypt.h"
 #include "splashy_funcs.h"
 
-int splashy_open() //char *mode)
+int splashy_open(int mode)
 {
+   int ret;
char * mode="suspend";
/* Do some detecting logic here ... */
-   if (!splashy_init (NULL,mode))
+   if ((ret = splashy_init (NULL,(mode==SPL_RESUME?"resume":"suspend"))) < 
0)
+   {
+   fprintf(stderr,"splashy_init: error %d",ret);
return -1;
-
-   if (splashy_start_splash () < 0)
-   return -1;
-
+   }
+   
+   if ((ret = splashy_start_splash ()) < 0) {
+   fprintf(stderr,"splashy_start_splash: error %d",ret);
+   return -2;
+   }
+   
return 0;
 }
 
Index: suspend.c
===
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.77
diff -u -r1.77 suspend.c
--- suspend.c   2 May 2007 20:55:43 -   1.77
+++ suspend.c   10 May 2007 20:01:14 -
@@ -1303,6 +1303,8 @@
 #endif
if (splash_param != 'y' && splash_param != 'Y')
splash_param = 0;
+   else
+   splash_param = SPL_SUSPEND;
 
if (early_writeout != 'n' && early_writeout != 'N')
early_writeout = 1;


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2

Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-24 Thread Tim Dijkstra
On Tue, 24 Apr 2007 00:56:02 +0200
Luca Tettamanti <[EMAIL PROTECTED]> wrote:

> Il Fri, Apr 20, 2007 at 06:59:11PM +0200, Stefan Seyfried ha scritto: 
> > On Wed, Apr 18, 2007 at 09:22:20PM +0200, Tim Dijkstra wrote:
> > > Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> > > > Well, it's possible to do something like this:
> > > > 
> > > > int s2ram_default_do(void) {
> > > > use /s/p/s
> > > > }
> > > > 
> > > > __attribute__((weak)) int s2ram_do(void) {
> > > > return s2ram_default_do();
> > > > }
> > > > 
> > > > and then in PPC code:
> > > > 
> > > > int s2ram_do(void) {
> > > > poke PMU;
> > > > 
> > > > return s2ram_default_do();
> > > > }
> > > 
> > > I must confess that I didn't know about these fancy weak-linking stuff,
> > > learned something new;) To me it seems a bit overkill, but logically it
> > > seems the OK, so be my guest...
> > 
> > For me, as a not-so-experienced C programmer, it is probably easier to
> > understand why there is some ppc-specific code in main(), either #ifdef'd
> > directly or simply where i know that this function is defined as NULL in
> > the !PPC case.
> > 
> > But i think i will also learn about this weak linking stuff if i actually
> > need to, so i don't care too much which way we go either ;-)
> 
> It's quite simple: a weak symbol may be discared by the linker if it
> found another copy.

Yes, but it reads a little less easier.
 
> This is the updated patch. You can either use the original 2/2 or this
> one:

OK looks good, if nobody objects. I'll commit this tomorrow. Thanks
Luca.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] swapfiles

2007-04-24 Thread Tim Dijkstra
On Tue, 24 Apr 2007 21:24:28 +0200
Tim Dijkstra <[EMAIL PROTECTED]> wrote:

> On Mon, 23 Apr 2007 23:34:58 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > On Monday, 23 April 2007 21:30, Tim Dijkstra wrote:
> > > On Sun, 22 Apr 2007 23:22:30 +0200
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Sunday, 22 April 2007 22:06, Tim Dijkstra wrote:
> > > > > On Sun, 22 Apr 2007 21:18:46 +0200
> > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > 
> > > > > > I think we have to debug the swap-file-on-LVM case more thoroughly.
> > > > > 
> > > > > OK, I've tried printing out /dev/resume_device + offset in mark_swap.
> > > > > Does the following seem reasonable?
> > > > > 
> > > > > 
> > > > > char ff[100];
> > > > > lseek(fd, shift, SEEK_SET);
> > > > > read(fd,ff,80);
> > > > > printf("The header (shift %u): %80s\n", shift, ff);
> > > > 
> > > > Yes, it does.
> > > > 
> > > > > It prints nothing ...
> > > > 
> > > > I thought it would.
> > > > 
> > > > Still, swap-offset doesn't fail, so it evidently is able to find the 
> > > > swap
> > > > signature in your file.
> > > 
> > > > Can you hack swap-offset.c so that it prints stat.st_rdev after calling 
> > > > fstat()
> > > > and run it on your swap file, then hack suspend.c so that it prints 
> > > > blkdev
> > > > in set_swap_file() and compare these two things?
> > > 
> > > stat.st_rdev == 0, but I think that's logical, because the swap _file_ is 
> > > not a
> > > device file.
> > > stat.st_dev == 64773 
> > > 
> > > Which is also the value of blkdev in suspend.
> > 
> > And which is strange, because s2disk uses stat.st_rdev .
> > 
> > Something fishy is going on here ...

I'm looking a bit closer into writing the image. I'm a bit confused. In
the case of a swap file we also need the offset. Indeed the function
set_swap_file uses that information. BTW the ioctl seem a bit counterintuitive  
you set a swap-file with ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
and a swap partition with  ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);

But then that information is not used in init_swap_writer. The only
thing we pass to that function is a file-descriptor pointing to the
device that contains the swap-file...

grts Tim



signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] swapfiles

2007-04-24 Thread Tim Dijkstra
On Mon, 23 Apr 2007 23:34:58 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Monday, 23 April 2007 21:30, Tim Dijkstra wrote:
> > On Sun, 22 Apr 2007 23:22:30 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > On Sunday, 22 April 2007 22:06, Tim Dijkstra wrote:
> > > > On Sun, 22 Apr 2007 21:18:46 +0200
> > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > > 
> > > > > I think we have to debug the swap-file-on-LVM case more thoroughly.
> > > > 
> > > > OK, I've tried printing out /dev/resume_device + offset in mark_swap.
> > > > Does the following seem reasonable?
> > > > 
> > > > 
> > > > char ff[100];
> > > > lseek(fd, shift, SEEK_SET);
> > > > read(fd,ff,80);
> > > > printf("The header (shift %u): %80s\n", shift, ff);
> > > 
> > > Yes, it does.
> > > 
> > > > It prints nothing ...
> > > 
> > > I thought it would.
> > > 
> > > Still, swap-offset doesn't fail, so it evidently is able to find the swap
> > > signature in your file.
> > 
> > > Can you hack swap-offset.c so that it prints stat.st_rdev after calling 
> > > fstat()
> > > and run it on your swap file, then hack suspend.c so that it prints blkdev
> > > in set_swap_file() and compare these two things?
> > 
> > stat.st_rdev == 0, but I think that's logical, because the swap _file_ is 
> > not a
> > device file.
> > stat.st_dev == 64773 
> > 
> > Which is also the value of blkdev in suspend.
> 
> And which is strange, because s2disk uses stat.st_rdev .
> 
> Something fishy is going on here ...

I don't know. stat.st_rdev in suspend.c comes from a stat() on
resume_dev_name and there I've put the name of the device containing
the swap file. That seemed to be the reasonable thing to do...

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Comments in usage()

2007-04-23 Thread Tim Dijkstra
On Mon, 23 Apr 2007 11:20:51 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 21, 2007 at 12:25:24AM +0200, Rafael J. Wysocki wrote:
> > On Saturday, 21 April 2007 00:14, Tim Dijkstra wrote:
> > > Hi,
> > > 
> > > S2ram could also use the usage() function from config.c to display its
> > > message. The only problem is that to replicate its current output we
> > > need to print comments too. To make this possible I made a little
> > > patch. The patch only works for s2disk currently, I didn't feel like
> > > adding the comments for s2ram/s2both if nobody likes the idea...
> > 
> > I like it. :-)
> 
>  ;-)
> 
> me, too.

Because everybody is so enthusiastic, I updated the patch so it
works for s2ram/s2both too;) 

I also added an -r,--resume_device option to s2disk/s2both/resume. The
device as the last element on the cli still, works and overrides the
option, but it is no longer showed in usage(), because that would be
inappropriate for s2ram.

Now the output looks like below, (we could loose the '[' and ']' IMHO). It's
not perfect, it is hard to align properly, especially because of the options
with arguments.

$ ./s2both -h
Usage: s2both [options]
  [-h|--help]   this message.
  [-f|--config ]alternative configuration file
  [-s|--image_size ]desired size of the image
  [-r|--resume_device ]  device that contains swap area
  [-o|--resume_offset ]  offset of swap file in resume device
  [--force] force suspending, even on unknown machines.

The following options are only available with --force:
  [--vbe_save]  save VBE state before suspending and restore after 
resume.
  [--vbe_post]  VBE POST the graphics card after resume.
  [--vbe_mode]  get VBE mode before suspend and set it after resume.
  [--radeontool]turn off the backlight on radeons before suspending.
  [--pci_save]  save the PCI config space for the VGA card.
  [--acpi_sleep ]   set the acpi_sleep parameter before suspend
1=s3_bios, 2=s3_mode, 3=both


Index: Makefile
===
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.54
diff -u -r1.54 Makefile
--- Makefile26 Mar 2007 21:44:04 -  1.54
+++ Makefile23 Apr 2007 20:09:17 -
@@ -22,7 +22,7 @@
 BINARIES=s2disk s2both s2ram swap-offset resume
 BINARIES_MIN=s2disk swap-offset
 
-S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
+S2RAM_OBJ=vt.o config.o vbetool/vbetool.o radeontool.o dmidecode.o
 SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 
 
 S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86
Index: config.c
===
RCS file: /cvsroot/suspend/suspend/config.c,v
retrieving revision 1.8
diff -u -r1.8 config.c
--- config.c1 Apr 2007 22:03:29 -   1.8
+++ config.c23 Apr 2007 20:09:17 -
@@ -104,23 +104,26 @@
return error;
 }
 
-void usage(char *my_name, struct option *options, const char *short_options)
+void usage(char *my_name, struct option_descr *options, const char 
*short_options)
 {
-   struct option *opt;
+   struct option_descr *opt;
 
-   printf("Usage: %s\t", my_name);
-   for (opt = options; opt->name; opt++) 
+   printf("Usage: %s [options]", my_name);
+   for (opt = options; opt->o.name; opt++) 
{
-   if (strchr(short_options,opt->val))
-   printf("[-%c|--%s", opt->val, opt->name);
+   if (strchr(short_options,opt->o.val))
+   printf("\n  [-%c|--%s", opt->o.val, opt->o.name);
else
-   printf("[--%s", opt->name);
+   printf("\n  [--%s", opt->o.name);
 
-   if (opt->has_arg)
-   printf(" <%s>]\n\t\t", opt->name);
+   if (opt->o.has_arg)
+   printf(" <%s>]", opt->o.name);
else
-   printf("]\n\t\t");
+   printf("]");
+
+   if (strlen(opt->descr))
+   printf("\t%s",opt->descr);
}
 
-   printf("[]\n");
+   printf("\n");
 }
Index: config.h
===
RCS file: /cvsroot/suspend/suspend/config.h,v
retrieving revision 1.5
diff -u -r1.5 config.h
--- config.h1 Apr 2007 22:03:29 -   1.5
+++ config.h23 Apr 2007 20:09:17 -
@@ -10,6 +10,8 @@
  *
  */
 
+#include 
+
 #define MAX_STR_LEN256
 
 struct config_par {
@@ -19,8 +21,13 @@
unsigne

Re: [Suspend-devel] swapfiles

2007-04-23 Thread Tim Dijkstra
On Sun, 22 Apr 2007 23:22:30 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Sunday, 22 April 2007 22:06, Tim Dijkstra wrote:
> > On Sun, 22 Apr 2007 21:18:46 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > I think we have to debug the swap-file-on-LVM case more thoroughly.
> > 
> > OK, I've tried printing out /dev/resume_device + offset in mark_swap.
> > Does the following seem reasonable?
> > 
> > 
> > char ff[100];
> > lseek(fd, shift, SEEK_SET);
> > read(fd,ff,80);
> > printf("The header (shift %u): %80s\n", shift, ff);
> 
> Yes, it does.
> 
> > It prints nothing ...
> 
> I thought it would.
> 
> Still, swap-offset doesn't fail, so it evidently is able to find the swap
> signature in your file.

> Can you hack swap-offset.c so that it prints stat.st_rdev after calling 
> fstat()
> and run it on your swap file, then hack suspend.c so that it prints blkdev
> in set_swap_file() and compare these two things?

stat.st_rdev == 0, but I think that's logical, because the swap _file_ is not a
device file.
stat.st_dev == 64773 

Which is also the value of blkdev in suspend.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] swapfiles

2007-04-22 Thread Tim Dijkstra
On Sun, 22 Apr 2007 21:18:46 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Sunday, 22 April 2007 11:40, Rafael J. Wysocki wrote:
> > On Sunday, 22 April 2007 01:02, Tim Dijkstra wrote:
> > > On Sat, 21 Apr 2007 23:14:48 +0200
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Saturday, 21 April 2007 22:36, Tim Dijkstra wrote:
> > > > > On Sat, 21 Apr 2007 11:30:22 +0200
> > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > On Saturday, 21 April 2007 00:59, Tim Dijkstra wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm trying out sdisk with a swap file. 
> > > > > > > 
> > > > > > > $ cat /proc/swaps
> > > > > > > FilenameTypeSize
> > > > > > > UsedPriority
> > > > > > > /dev/hda2   partition   979956  
> > > > > > > 189972  -1
> > > > > > > /local/tmp/swapfile file1048568 0 
> > > > > > >   -2
> > > > > > > 
> > > > > > > Now what maybe complicates things is that mounted on /local is an 
> > > > > > > lvm
> > > > > > > logical volume, /dev/dm-5
> > > > > > > 
> > > > > 
> > > > > > 
> > > > > > First, try the built-in swsusp.
> > > > > 
> > > > > Doesn't work. 
> > > > > $ cat /proc/cmdline
> > > > > root=/dev/hda1 ro acpi_sleep=s3_bios,s3_mode vga=0x0330 
> > > > > resume=/dev/dm-5 resume_offset=12979490
> > > > > 
> > > > > The result of `echo disk > /sys/power/state':
> > > > > 
> > > > > Wrote ... kbytes in ... sec
> > > > > S<6>attempt to access beyond end of device
> > > > > hda2: rw=16, want=103835928, limit=1959930
> > > > > read-error on swap-device (3:2:103835928)
> > > > > swsusp: Swap header not found!
> > > > > 
> > > > > 
> > > > > BTW, /dev/hda2 is my other swap partition... Should I do anything else
> > > > > except specifying resume en resume_offset on the command-line?
> > > > 
> > > > Ouch, sorry.  That has no chance to work, because /dev/dm-5 is not 
> > > > known to the
> > > > kernel before LVMs are initialized which happens after the resume kicks 
> > > > in, so
> > > > swsusp gets confused.
> > > 
> > > OK, but this is at suspend, then /dev/dm-5 is known.
> > 
> > This doesn't matter, because the resume device is selected at boot time.
> > 
> > > And this problem shouldn't be a problem in the case of uswsusp, should it?
> > 
> > No, it shouldn't.
> > 
> > I'll try to debug it a little later today, but I have no LVM setup handy.
> 
> I've tested with a swap on a "regular" partition and it works as expected.
> If provided with the right swap offset (as returned by swap-offset from a
> recent CVS), suspends and resumes.  When provided with a wrong offset,
> refuses to do anything.
> 
> I think we have to debug the swap-file-on-LVM case more thoroughly.

OK, I've tried printing out /dev/resume_device + offset in mark_swap.
Does the following seem reasonable?


char ff[100];
lseek(fd, shift, SEEK_SET);
read(fd,ff,80);
printf("The header (shift %u): %80s\n", shift, ff);


It prints nothing ...

grts Tim






signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] swapfiles

2007-04-21 Thread Tim Dijkstra
On Sat, 21 Apr 2007 23:14:48 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Saturday, 21 April 2007 22:36, Tim Dijkstra wrote:
> > On Sat, 21 Apr 2007 11:30:22 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > On Saturday, 21 April 2007 00:59, Tim Dijkstra wrote:
> > > > Hi,
> > > > 
> > > > I'm trying out sdisk with a swap file. 
> > > > 
> > > > $ cat /proc/swaps
> > > > FilenameTypeSizeUsed
> > > > Priority
> > > > /dev/hda2   partition   979956  189972  
> > > > -1
> > > > /local/tmp/swapfile file1048568 0   
> > > > -2
> > > > 
> > > > Now what maybe complicates things is that mounted on /local is an lvm
> > > > logical volume, /dev/dm-5
> > > > 
> > 
> > > 
> > > First, try the built-in swsusp.
> > 
> > Doesn't work. 
> > $ cat /proc/cmdline
> > root=/dev/hda1 ro acpi_sleep=s3_bios,s3_mode vga=0x0330 resume=/dev/dm-5 
> > resume_offset=12979490
> > 
> > The result of `echo disk > /sys/power/state':
> > 
> > Wrote ... kbytes in ... sec
> > S<6>attempt to access beyond end of device
> > hda2: rw=16, want=103835928, limit=1959930
> > read-error on swap-device (3:2:103835928)
> > swsusp: Swap header not found!
> > 
> > 
> > BTW, /dev/hda2 is my other swap partition... Should I do anything else
> > except specifying resume en resume_offset on the command-line?
> 
> Ouch, sorry.  That has no chance to work, because /dev/dm-5 is not known to 
> the
> kernel before LVMs are initialized which happens after the resume kicks in, so
> swsusp gets confused.

OK, but this is at suspend, then /dev/dm-5 is known. And this problem shouldn't
be a problem in the case of uswsusp, should it?

> However, it shouldn't even try to write anything in that case.  I'm afraid 
> that
> the kernel needs fixing.
> 
> Anyway, I think the problem is related to the fact that the swap file is
> on the LVM.  Can you try with a swap file on a non-LVM fs?

Well, that will have to wait, but I also got a rapport from somebody
(cc-ing brandon) who has the same symptoms with uswsusp and swap-files.
He has a very simple setup with only one regular partition with a
swapfile. Brandon did you also try the built-in swsusp?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] swapfiles

2007-04-21 Thread Tim Dijkstra
On Sat, 21 Apr 2007 11:30:22 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Saturday, 21 April 2007 00:59, Tim Dijkstra wrote:
> > Hi,
> > 
> > I'm trying out sdisk with a swap file. 
> > 
> > $ cat /proc/swaps
> > FilenameTypeSizeUsed
> > Priority
> > /dev/hda2   partition   979956  189972  -1
> > /local/tmp/swapfile file1048568 0   -2
> > 
> > Now what maybe complicates things is that mounted on /local is an lvm
> > logical volume, /dev/dm-5
> > 

> 
> First, try the built-in swsusp.

Doesn't work. 
$ cat /proc/cmdline
root=/dev/hda1 ro acpi_sleep=s3_bios,s3_mode vga=0x0330 resume=/dev/dm-5 
resume_offset=12979490

The result of `echo disk > /sys/power/state':

Wrote ... kbytes in ... sec
S<6>attempt to access beyond end of device
hda2: rw=16, want=103835928, limit=1959930
read-error on swap-device (3:2:103835928)
swsusp: Swap header not found!


BTW, /dev/hda2 is my other swap partition... Should I do anything else
except specifying resume en resume_offset on the command-line?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] swapfiles

2007-04-20 Thread Tim Dijkstra
Hi,

I'm trying out sdisk with a swap file. 

$ cat /proc/swaps
FilenameTypeSizeUsedPriority
/dev/hda2   partition   979956  189972  -1
/local/tmp/swapfile file1048568 0   -2

Now what maybe complicates things is that mounted on /local is an lvm
logical volume, /dev/dm-5

I configured /etc/suspend.conf with the help of swap-offset

$ sudo swap-offset /local/tmp/swapfile
resume offset = 12979490

This is with a vanilla kernel
$ uname -r
2.6.20

Now if I start s2disk I get all the way too the "S", but then I get
thrown back in my session. A printf tells me that in the function
mark_swap() the condition:

if (!memcmp("SWAP-SPACE", swsusp_header.sig, 10) ||
!memcmp("SWAPSPACE2", swsusp_header.sig, 10)) {

is false.

Somehow the header is not what s2disk thinks it is...

Any ideas?

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Comments in usage()

2007-04-20 Thread Tim Dijkstra
Hi,

S2ram could also use the usage() function from config.c to display its
message. The only problem is that to replicate its current output we
need to print comments too. To make this possible I made a little
patch. The patch only works for s2disk currently, I didn't feel like
adding the comments for s2ram/s2both if nobody likes the idea...

The `s2both -h' output now looks like:

Usage: s2disk
  [-h|--help]   This message
  [-f|--config ]Alternative configuration file
  [-s|--image_size ]Desired size of the image
  [-o|--resume_offset ]  Offset of swap file in resume device
  []


Index: config.h
===
RCS file: /cvsroot/suspend/suspend/config.h,v
retrieving revision 1.5
diff -u -r1.5 config.h
--- config.h1 Apr 2007 22:03:29 -   1.5
+++ config.h20 Apr 2007 22:04:43 -
@@ -10,6 +10,8 @@
  *
  */
 
+#include 
+
 #define MAX_STR_LEN256
 
 struct config_par {
@@ -19,8 +21,13 @@
unsigned int len;
 };
 
+struct option_descr {
+   struct option o;
+   const char *descr;
+};
+
 int parse(char *my_name, char *file_name, int parc, struct config_par *parv);
 
-void usage(char *my_name, struct option options[], const char *short_options);
+void usage(char *my_name, struct option_descr options[], const char 
*short_options);
 
 #define CONFIG_FILE"/etc/suspend.conf"

Index: suspend.c
===
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.76
diff -u -r1.76 suspend.c
--- suspend.c   3 Apr 2007 19:32:34 -   1.76
+++ suspend.c   20 Apr 2007 22:04:44 -
@@ -1169,15 +1169,20 @@
 /* Parse the command line and/or configuration file */
 static inline int get_config(int argc, char *argv[])
 {
-   static struct option options[] = {
-   { "help",   no_argument,NULL, 'h'},
-   { "config", required_argument,  NULL, 'f'},
-   { "image_size", required_argument,  NULL, 's'},
-   { "resume_offset",  required_argument,  NULL, 'o'},
+   static struct option_descr options[] = {
+   {   { "help",   no_argument,NULL, 'h'}, 
+   "\t\t\tThis message"},
+   {   { "config", required_argument,  NULL, 'f'},
+   "\tAlternative configuration file"},
+   {   { "image_size", required_argument,  NULL, 's'},
+   "Desired size of the image"},
+   {   { "resume_offset",  required_argument,  NULL, 'o'},
+   "Offset of swap file in resume device"},
 #ifdef CONFIG_BOTH
HACKS_LONG_OPTS
 #endif
-   { NULL, 0,  NULL,  0 }
+   {   { NULL, 0,  NULL,  0 },
+   ""}
};
int i, error;
char *conf_name = CONFIG_FILE;
@@ -1187,7 +1192,7 @@
unsigned long int im_size = 0;
const char *optstring = "hf:s:o:";
 
-   while ((i = getopt_long(argc, argv, optstring, options, NULL)) != -1) {
+   while ((i = getopt_long(argc, argv, optstring, (struct option *) 
options, NULL)) != -1) {
switch (i) {
case 'h':
usage(my_name, options, optstring);

Index: config.c
===
RCS file: /cvsroot/suspend/suspend/config.c,v
retrieving revision 1.8
diff -u -r1.8 config.c
--- config.c1 Apr 2007 22:03:29 -   1.8
+++ config.c20 Apr 2007 22:04:43 -
@@ -104,23 +104,29 @@
return error;
 }
 
-void usage(char *my_name, struct option *options, const char *short_options)
+void usage(char *my_name, struct option_descr *options, const char 
*short_options)
 {
-   struct option *opt;
+   struct option_descr *opt;
 
-   printf("Usage: %s\t", my_name);
-   for (opt = options; opt->name; opt++) 
+   printf("Usage: %s\n  ", my_name);
+   for (opt = options; opt->o.name; opt++) 
{
-   if (strchr(short_options,opt->val))
-   printf("[-%c|--%s", opt->val, opt->name);
+   if (strchr(short_options,opt->o.val))
+   printf("[-%c|--%s", opt->o.val, opt->o.name);
else
-   printf("[--%s", opt->name);
+   printf("[--%s", opt->o.name);
 
-   if (opt->has_arg)
-   printf(" <%s>]\n\t\t", opt->name);
+   if (opt->o.has_arg)
+   printf(" <%s>]", opt->o.name);
else
-   printf("]\n\t\t");
+   printf("]");
+
+   if (strlen(opt->descr))
+   printf("\t%s",opt->descr);
+
+   printf("\n  ");
}
 
+
printf("[

Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-18 Thread Tim Dijkstra
On Mon, 16 Apr 2007 23:22:32 +0200
Luca Tettamanti <[EMAIL PROTECTED]> wrote:

> Il Mon, Apr 16, 2007 at 10:35:25PM +0200, Tim Dijkstra ha scritto: 
> > On Sun, 15 Apr 2007 02:36:12 +0200
> > Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> > 
> > > > @@ -27,7 +27,16 @@
> > > >  int s2ram_do(void)
> > > >  {
> > > > int ret = 0;
> > > > -   FILE *f = fopen("/sys/power/state", "w");
> > > > +   FILE *f;
> > > > +
> > > > +   /* If this works we're done. Else we just continue as if 
> > > > nothing 
> > > > +* happened, future kernels will work with /s/p/s. */
> > > > +   ret = s2ram_do_pmu();
> > > > +   if (!ret)
> > > > +   return ret;
> > > > +   ret = 0;
> > > > +   
> > > > +   f = fopen("/sys/power/state", "w");
> > > > if (!f) {
> > > > printf("/sys/power/state does not exist; what kind of 
> > > > ninja mutant machine is this?\n");
> > > > return ENODEV;  
> > > 
> > > This is what I was trying to avoid. PMU in generic code is not nice.
> > > I've corrected the 'ARCH' bug above and added headers as per Pavel's
> > > comment.
> > > 
> > > Anyway, since PPC actually wants to override (as in "do something
> > > different") s2ram_do it's also possibile to make it a weak symbol so
> > > that s2ram-ppc.c can provides its own implementation, will generic code
> > > contains a sensitive default. I'm attacching a patch with the weak
> > > symbol version.
> > 
> > I don't think the s2ram_do_pmu call is that problematic to have in the
> > generic code. 
> > 
> > The trade of have to make is, do we want to duplicate
> > the /sys/power/state stuff or do we want an empty function in x86 piece
> > of the code.
> > 
> > I think the latter is better choice.
> 
> Well, it's possible to do something like this:
> 
> int s2ram_default_do(void) {
> use /s/p/s
> }
> 
> __attribute__((weak)) int s2ram_do(void) {
> return s2ram_default_do();
> }
> 
> and then in PPC code:
> 
> int s2ram_do(void) {
> poke PMU;
> 
> return s2ram_default_do();
> }

I must confess that I didn't know about these fancy weak-linking stuff,
learned something new;) To me it seems a bit overkill, but logically it
seems the OK, so be my guest...

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Bug#415441: s2disk and raid

2007-04-17 Thread Tim Dijkstra
On Thu, 12 Apr 2007 00:37:53 -0500
Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> wrote:


> On Thu, Apr 05, 2007 at 12:47:49AM +0400, Michael Tokarev wrote:
> > Neil Brown wrote:
> > > On Tuesday April 3, [EMAIL PROTECTED] wrote:
> > []
> > >> After the power cycle the kernel boots, devices are discovered, among
> > >> which the ones holding raid. Then we try to find the device that holds
> > >> swap in case of resume and / in case of a normal boot.
> > >>
> > >> Now comes a crucial point. The script that finds the raid array, finds
> > >> the array in an unclean state and starts syncing.
> > []
> > > So you can start arrays 'readonly', and resume off a raid1 without any
> > > risk of the the resync starting when it shouldn't.
> > 

> Something that I seem to not have said. It's not *all* arrays that are
> unclean on reboot, just one (that is used as physical volume for
> LVM. I don't know if that's relevant). Also worth mentioning is that
> kernel space suspend on 2.6.17 did not have this problem (or didn't
> show it in my system, anyways).
> 
> After reading through the responses, I have come to think this is a
> kernel issue, and have posted a report (#418823) to debian's linux-2.6
> package. I'll wait to see what they have to say.

Maybe there is a kernel issue, but we still are doing something wrong;
We shouldn't try to write to raid before we resume, that is just asking
for problems.

I'll look into the `readonly' option. That would fix or problem IMHO.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-16 Thread Tim Dijkstra
On Sun, 15 Apr 2007 02:36:12 +0200
Luca Tettamanti <[EMAIL PROTECTED]> wrote:

> > @@ -27,7 +27,16 @@
> >  int s2ram_do(void)
> >  {
> > int ret = 0;
> > -   FILE *f = fopen("/sys/power/state", "w");
> > +   FILE *f;
> > +
> > +   /* If this works we're done. Else we just continue as if nothing 
> > +* happened, future kernels will work with /s/p/s. */
> > +   ret = s2ram_do_pmu();
> > +   if (!ret)
> > +   return ret;
> > +   ret = 0;
> > +   
> > +   f = fopen("/sys/power/state", "w");
> > if (!f) {
> > printf("/sys/power/state does not exist; what kind of ninja 
> > mutant machine is this?\n");
> > return ENODEV;  
> 
> This is what I was trying to avoid. PMU in generic code is not nice.
> I've corrected the 'ARCH' bug above and added headers as per Pavel's
> comment.
> 
> Anyway, since PPC actually wants to override (as in "do something
> different") s2ram_do it's also possibile to make it a weak symbol so
> that s2ram-ppc.c can provides its own implementation, will generic code
> contains a sensitive default. I'm attacching a patch with the weak
> symbol version.

I don't think the s2ram_do_pmu call is that problematic to have in the
generic code. 

The trade of have to make is, do we want to duplicate
the /sys/power/state stuff or do we want an empty function in x86 piece
of the code.

I think the latter is better choice.

grts Tim


signature.asc
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-14 Thread Tim Dijkstra
Hi,

This patch fixes all my concerns I raised in the previous e-mail. It
applies on top of lucas patch. So if you apply 1/2, I'll do this one
on top. If everybody agrees that is...

grts 

diff -urN a/Makefile b/Makefile
--- a/Makefile  2007-04-14 22:55:32.0 +0200
+++ b/Makefile  2007-04-14 22:52:34.0 +0200
@@ -14,7 +14,7 @@
 
 ###
 
-ARCH:=$(shell uname -m)
+ARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/ppc.*/ppc/)
 
 CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
 LD_FLAGS=-L/usr/local/lib
@@ -22,11 +22,18 @@
 BINARIES=s2disk s2both s2ram swap-offset resume
 BINARIES_MIN=s2disk swap-offset
 
-S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
+S2RAM_OBJ=vt.o
 SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 
 
-S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86
+S2RAM_LD_FLAGS = $(LD_FLAGS)
 SWSUSP_LD_FLAGS = $(LD_FLAGS)
+ARCH=ppc
+ifeq ($(ARCH), x86)
+   S2RAM_OBJ += s2ram-x86.o dmidecode.o radeontool.o vbetool/vbetool.o
+   S2RAM_LD_FLAGS += -lx86 -lpci -lz
+else ifeq ($(ARCH), ppc)  
+   S2RAM_OBJ += s2ram-ppc.o
+endif
 
 ifndef CONFIG_RESUME_DYN
 STATIC_LD_FLAGS = -static
@@ -81,13 +88,13 @@
$(CC) $(CC_FLAGS) -DCONFIG_BOTH -c $< -o $@
 
 s2ram.o: s2ram.c s2ram.h whitelist.c
-   $(CC) $(CC_FLAGS) -include s2ram-x86.h -c $< -o $@
+   $(CC) $(CC_FLAGS) -include s2ram-$(ARCH).h -c $< -o $@
 
 md5.o encrypt.o: %.o : %.c %.h md5.h
$(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@
 
 # Simple objects with header
-config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/vbetool.o: %.o : 
%.c %.h
+config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/vbetool.o 
s2ram-ppc.o s2ram-x86.o: %.o : %.c %.h
$(CC) $(CC_FLAGS) -c $< -o $@
 
 # Simple object without header
@@ -98,11 +105,11 @@
 s2disk:$(SWSUSP_OBJ) suspend.c
$(CC) -g $(CC_FLAGS)  $^ -o $@ $(SWSUSP_LD_FLAGS)
 
-s2ram: $(S2RAM_OBJ) s2ram.o s2ram-x86.o
+s2ram: $(S2RAM_OBJ) s2ram.o
$(CC) -g $(CC_FLAGS)  $^ -o $@ $(S2RAM_LD_FLAGS)
 
-s2both:$(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c s2ram-x86.o
-   $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-x86.h $^ -o $@ 
$(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)
+s2both:$(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c
+   $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-$(ARCH).h  $^ -o $@ 
$(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)
 
 resume:resume.c $(SWSUSP_OBJ)
$(CC) $(CC_FLAGS) $(STATIC_CC_FLAGS) $^ -o $@ $(STATIC_LD_FLAGS) 
$(SWSUSP_LD_FLAGS)
diff -urN a/s2ram.c b/s2ram.c
--- a/s2ram.c   2007-04-14 21:51:22.0 +0200
+++ b/s2ram.c   2007-04-14 22:52:34.0 +0200
@@ -27,7 +27,16 @@
 int s2ram_do(void)
 {
int ret = 0;
-   FILE *f = fopen("/sys/power/state", "w");
+   FILE *f;
+
+   /* If this works we're done. Else we just continue as if nothing 
+* happened, future kernels will work with /s/p/s. */
+   ret = s2ram_do_pmu();
+   if (!ret)
+   return ret;
+   ret = 0;
+   
+   f = fopen("/sys/power/state", "w");
if (!f) {
printf("/sys/power/state does not exist; what kind of ninja 
mutant machine is this?\n");
return ENODEV;
diff -urN a/s2ram.h b/s2ram.h
--- a/s2ram.h   2007-04-14 21:51:22.0 +0200
+++ b/s2ram.h   2007-04-14 22:52:34.0 +0200
@@ -30,5 +30,5 @@
 int s2ram_do(void);
 void s2ram_resume(void);
 void s2ram_add_flag(int opt, const char *arg);
-
+int s2ram_do_pmu(void);
 
diff -urN a/s2ram-ppc.c b/s2ram-ppc.c
--- a/s2ram-ppc.c   1970-01-01 01:00:00.0 +0100
+++ b/s2ram-ppc.c   2007-04-14 22:52:34.0 +0200
@@ -0,0 +1,81 @@
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "s2ram.h"
+
+void s2ram_usage_platform(void) {
+   /* No additional options for PPC */
+}
+
+void s2ram_add_flag(int opt, const char *arg) {
+}
+
+int s2ram_prepare(void)
+{
+   return 0;
+}
+
+void s2ram_resume(void)
+{
+   /* nop */
+}
+
+void identify_machine(void) {
+   /* TODO */
+}
+
+int s2ram_hacks(void) {
+   return 0;
+}
+
+int s2ram_is_supported(void) {
+   int fd, ret = 0;
+   unsigned long arg = 0;
+
+   /* PMU_IOC_CAN_SLEEP is going away, so we only say unsupported
+* if PMU_IOC_CAN_SLEEP explicitly says we can't */
+   fd = open("/dev/pmu", O_RDWR);
+   if (fd < 0)
+   return 0;
+
+   ret = ioctl(fd, PMU_IOC_CAN_SLEEP, &arg);
+   if (!ret && arg != 1)
+   ret = ENOTSUP;
+
+   close(fd);
+
+   return 0;
+}
+
+int s2ram_do_pmu (void) {
+   int fd;
+   int ret = 0;
+   unsigned long arg = 0;
+
+   fd = open("/dev/pmu", O_RDWR);
+   if (fd < 0)
+   return errno;
+
+   ret = ioctl(fd, PMU_IOC_CAN_SLEEP, &arg);
+   if (!ret && arg != 1)
+   ret = ENOTSUP;
+
+   if (

Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-14 Thread Tim Dijkstra
On Wed, 11 Apr 2007 00:19:35 +0200
Luca Tettamanti <[EMAIL PROTECTED]> wrote:

> Add s2ram support for PPC architecture. s2ram.{c,h} contain the
> implementation of the required functions, used by the main file. The
> Makefile selects the correct platform files using $(ARCH) variable
> (autodetected by default, can be overridden).
> 
> PPC code is based on original patch from Tim Dijkstra.
> 
> Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
> 
> ---
>  Makefile|   22 +++-
>  s2ram-ppc.c |   75 
>  s2ram-ppc.h |2 +
>  3 files changed, 93 insertions(+), 6 deletions(-)
> --- a/Makefile2007-04-10 23:46:38.0 +0200
> +++ b/Makefile2007-04-10 23:47:11.0 +0200
> @@ -14,7 +14,17 @@
>  
>  ###
>  
> -ARCH:=$(shell uname -m)
> +ARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
> + -e s/arm.*/arm/ -e s/sa110/arm/ \
> + -e s/s390x/s390/ -e s/parisc64/parisc/ \
> + -e s/ppc.*/ppc/ -e s/mips.*/mips/ )
> +

This seems a bit overkill, I don't think we'll ever support s390 or parisc.
And if we do we can add them then. x86 and ppc seems enough for me. According

> +is_arch = $(shell test $(ARCH) == $(1) && echo 1)
> +
> +ifeq ($(call is_arch, "x86"), 1)
> + s2ram_extra = dmidecode.o radeontool.o vbetool/vbetool.o
> +endif

Why can't we do ifeq ($(ARCH), x86) ?

>  CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
>  LD_FLAGS=-L/usr/local/lib
> @@ -22,7 +32,7 @@
>  BINARIES=s2disk s2both s2ram swap-offset resume
>  BINARIES_MIN=s2disk swap-offset
>  
> -S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
> +S2RAM_OBJ=vt.o $(s2ram_extra)
>  SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 
>  
>  S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86

-lx86 -lpcu -lz are only necessary for s2ram-x86.o

> @@ -81,7 +91,7 @@
>   $(CC) $(CC_FLAGS) -DCONFIG_BOTH -c $< -o $@
>  
>  s2ram.o: s2ram.c s2ram.h whitelist.c
> - $(CC) $(CC_FLAGS) -include s2ram-x86.h -c $< -o $@
> + $(CC) $(CC_FLAGS) -include s2ram-$(ARCH).h -c $< -o $@
>  
>  md5.o encrypt.o: %.o : %.c %.h md5.h
>   $(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@
> @@ -98,11 +108,11 @@
>  s2disk:  $(SWSUSP_OBJ) suspend.c
>   $(CC) -g $(CC_FLAGS)  $^ -o $@ $(SWSUSP_LD_FLAGS)
>  
> -s2ram:   $(S2RAM_OBJ) s2ram.o s2ram-x86.o
> +s2ram:   $(S2RAM_OBJ) s2ram.o s2ram-$(ARCH).o
>   $(CC) -g $(CC_FLAGS)  $^ -o $@ $(S2RAM_LD_FLAGS)
>  
> -s2both:  $(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c s2ram-x86.o
> - $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-x86.h $^ -o $@ 
> $(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)
> +s2both:  $(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c 
> s2ram-$(ARCH).o
> + $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-$(ARCH).h  $^ -o $@ 
> $(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)

We can add s2ram-$(ARCH) to $(S2RAM_OBJ)

>  resume:  resume.c $(SWSUSP_OBJ)
>   $(CC) $(CC_FLAGS) $(STATIC_CC_FLAGS) $^ -o $@ $(STATIC_LD_FLAGS) 
> $(SWSUSP_LD_FLAGS)

There is not rule for s2ram-ppc.o nor s2ram-x86.o

> --- a/s2ram-ppc.c 1970-01-01 01:00:00.0 +0100
> +++ b/s2ram-ppc.c 2007-04-10 23:28:09.0 +0200
> +int s2ram_is_supported(void) {
> + int fd;
> + int ret = 0;
> + unsigned long arg = 0;
> +
> + fd = open("/dev/pmu", O_RDWR);
> + if (fd < 0)
> + return errno;
> +
> + ret = ioctl(fd, PMU_IOC_CAN_SLEEP, &arg);
> + if (!ret && arg != 1)
> + ret = ENOTSUP;
> +
> + close(fd);
> +
> + return ret;
> +}
> +
> +int s2ram_hacks(void) {
> + int fd;
> + int ret;
> + unsigned long args;
> +
> + fd = open("/dev/pmu", O_RDWR);
> + if (fd < 0)
> + return errno;
> +
> + ret = ioctl(fd, PMU_IOC_SLEEP, 0);
> + if (ret)
> + ret = errno;
> +
> + close(fd);
> +
> + /* Fake return value: if PMU_IOC_SLEEP failed we return success so that
> +  * s2ram tries with "echo mem > /sys/power/state". On success we
> +  * return EINPROGRESS to make s2ram exit.
> +  */
> + if (!ret)
> + return EINPROGRESS;
> + else
> + return 0;
> +}

This doesn't take into account the usage in s2both. There s2ram_hacks
is called early on. The actual trigger to suspend is done by doing
ioctl(/dev/snaphost,SUSPEND_TO

Re: [Suspend-devel] [PATCH 2/2] s2ram: add PPC support

2007-04-11 Thread Tim Dijkstra
Luca Tettamanti schreef:
> Add s2ram support for PPC architecture. s2ram.{c,h} contain the
> implementation of the required functions, used by the main file. The
> Makefile selects the correct platform files using $(ARCH) variable
> (autodetected by default, can be overridden).
>
> PPC code is based on original patch from Tim Dijkstra.

I haven't looked to closely at it, I can't access my machine right now.
But this patch doesn't seem correct. IIRC, s2ram_hacks is called before we
really suspend the system, but the ppc version would. I'll take a closer
look tomorrow night.

> Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
>
> ---
>  Makefile|   22 +++-
>  s2ram-ppc.c |   75
> 
>  s2ram-ppc.h |2 +
>  3 files changed, 93 insertions(+), 6 deletions(-)
> --- a/Makefile2007-04-10 23:46:38.0 +0200
> +++ b/Makefile2007-04-10 23:47:11.0 +0200
> @@ -14,7 +14,17 @@
>
>  ###
>
> -ARCH:=$(shell uname -m)
> +ARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
> + -e s/arm.*/arm/ -e s/sa110/arm/ \
> + -e s/s390x/s390/ -e s/parisc64/parisc/ \
> + -e s/ppc.*/ppc/ -e s/mips.*/mips/ )
> +
> +
> +is_arch = $(shell test $(ARCH) == $(1) && echo 1)
> +
> +ifeq ($(call is_arch, "x86"), 1)
> + s2ram_extra = dmidecode.o radeontool.o vbetool/vbetool.o
> +endif
>
>  CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
>  LD_FLAGS=-L/usr/local/lib
> @@ -22,7 +32,7 @@
>  BINARIES=s2disk s2both s2ram swap-offset resume
>  BINARIES_MIN=s2disk swap-offset
>
> -S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
> +S2RAM_OBJ=vt.o $(s2ram_extra)
>  SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o
>
>  S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86
> @@ -81,7 +91,7 @@
>   $(CC) $(CC_FLAGS) -DCONFIG_BOTH -c $< -o $@
>
>  s2ram.o: s2ram.c s2ram.h whitelist.c
> - $(CC) $(CC_FLAGS) -include s2ram-x86.h -c $< -o $@
> + $(CC) $(CC_FLAGS) -include s2ram-$(ARCH).h -c $< -o $@
>
>  md5.o encrypt.o: %.o : %.c %.h md5.h
>   $(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@
> @@ -98,11 +108,11 @@
>  s2disk:  $(SWSUSP_OBJ) suspend.c
>   $(CC) -g $(CC_FLAGS)  $^ -o $@ $(SWSUSP_LD_FLAGS)
>
> -s2ram:   $(S2RAM_OBJ) s2ram.o s2ram-x86.o
> +s2ram:   $(S2RAM_OBJ) s2ram.o s2ram-$(ARCH).o
>   $(CC) -g $(CC_FLAGS)  $^ -o $@ $(S2RAM_LD_FLAGS)
>
> -s2both:  $(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c s2ram-x86.o
> - $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-x86.h $^ -o $@
> $(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)
> +s2both:  $(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c 
> s2ram-$(ARCH).o
> + $(CC) -g $(CC_FLAGS) -DCONFIG_BOTH -include s2ram-$(ARCH).h  $^ -o $@
> $(SWSUSP_LD_FLAGS) $(S2RAM_LD_FLAGS)
>
>  resume:  resume.c $(SWSUSP_OBJ)
>   $(CC) $(CC_FLAGS) $(STATIC_CC_FLAGS) $^ -o $@ $(STATIC_LD_FLAGS)
> $(SWSUSP_LD_FLAGS)
> --- a/s2ram-ppc.c 1970-01-01 01:00:00.0 +0100
> +++ b/s2ram-ppc.c 2007-04-10 23:28:09.0 +0200
> @@ -0,0 +1,75 @@
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "s2ram.h"
> +
> +void s2ram_usage_platform(void) {
> + /* No additional options for PPC */
> +}
> +
> +void s2ram_add_flag(int opt, const char *arg) {
> +}
> +
> +int s2ram_prepare(void)
> +{
> + return 0;
> +}
> +
> +void s2ram_resume(void)
> +{
> + /* nop */
> +}
> +
> +void identify_machine(void) {
> + /* TODO */
> +}
> +
> +int s2ram_is_supported(void) {
> + int fd;
> + int ret = 0;
> + unsigned long arg = 0;
> +
> + fd = open("/dev/pmu", O_RDWR);
> + if (fd < 0)
> + return errno;
> +
> + ret = ioctl(fd, PMU_IOC_CAN_SLEEP, &arg);
> + if (!ret && arg != 1)
> + ret = ENOTSUP;
> +
> + close(fd);
> +
> + return ret;
> +}
> +
> +int s2ram_hacks(void) {
> + int fd;
> + int ret;
> + unsigned long args;
> +
> + fd = open("/dev/pmu", O_RDWR);
> + if (fd < 0)
> + return errno;
> +
> + ret = ioctl(fd, PMU_IOC_SLEEP, 0);
> + if (ret)
> + ret = errno;
> +
> + close(fd);
> +
> + /* Fake return value: if PMU_IOC_SLEEP failed we return success so that
&

Re: [Suspend-devel] [patch] pass down argv[0] to error messages

2007-04-09 Thread Tim Dijkstra
On Tue, 3 Apr 2007 21:32:39 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

>  #define suspend_error(msg, args...) \
>  do { \
> - fprintf(stderr, "suspend: " msg " Reason: %m\n", ## args); \
> + fprintf(stderr, "%s: " msg " Reason: %m\n", my_name, ## args); \
>  } while (0); 

> > > > What is this do { } while (0); thing good for?  
> > > 
> > > gcc magic, there is a good reason for it (something about breaking build
> > > instead of misbehaving at runtime), but i always foreget it.  
> > 
> > http://kernelnewbies.org/FAQ/DoWhile0
> > 
> > BTW, the ending semicolon is not necessary.  
> 
> Yes. AFAICS it is even harmful, so i'll remove it in an extra commit.

If I read the FAQ above correctly the `do {} while (0);' thing is only
necessary if you want have more than one statement in your macro. It is
used to logically group stuff together. In this case it is unnecessary.

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] CONFIG_PPC

2007-04-05 Thread Tim Dijkstra
Hi,

A while back I proposed a patch to support powerpc. The comments where
that it was a bit ugly with all those #ifdef's. Now the question is how
do I do this neatly?

Of all the functions in s2ram there is only one that would be really
duplicated. Then there is main() en a few functions that we would need
because they are part of the interface that suspend.c uses.

I could solve this as Stefan suggested like this:

#ifdef CONFIG_PPC
int s2ram_hacks(void) return 0;
#else
int s2ram_hacks(void)
{
int ret = 0;

/* 0 means: don't touch what was set on kernel commandline */
if (flags & (S3_BIOS | S3_MODE))
.
.
.
}
#end

for a few functions. Still I would put a large part in #ifdef/#end
blocks, just because it is not used. Also there will be some #ifdefs left
in main.

Would that be acceptable? Any other ideas?

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2disk and raid

2007-04-04 Thread Tim Dijkstra
On Wed, 4 Apr 2007 15:20:56 +1000
Neil Brown <[EMAIL PROTECTED]> wrote:

> On Tuesday April 3, [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > I've got a bugreport [0] from a user trying to use raid and uswsusp. He's
> > using initramfs-tools available in debian. I'll describe the problem
> > and my analysis, maybe you can comment on what you think. A warning: I only
> > have a casual understanding of raid, never looked at any code related to it.
> > 
> > This is a setup where root maybe on raid, but swap isn't. Swap on raid
> > will be very difficult to support, I think.
> 
> Nah... shouldn't be a problem well, maybe raid5.

OK, that is nice to hear.

> > 
> > When s2disk is started, nothing special is done to the array. It may be
> > in an unclean state (just like filesystems). Image is written to disk.
> > 
> > After the power cycle the kernel boots, devices are discovered, among
> > which the ones holding raid. Then we try to find the device that holds
> > swap in case of resume and / in case of a normal boot.
> > 
> > Now comes a crucial point. The script that finds the raid array, finds
> > the array in an unclean state and starts syncing.
> 
> Uhm, so you are finding the device for the root filesystem before you
> have decided which case it will be (resume or normal boot).  Can that
> be delayed until after the decision.  It's probably not important but
> it seems neater.
> Or do you need the root device even when resuming (I guess if swap is
> in a file on the root filesystem)

It is not that we need the root filesystem for resume. It is more how
the initramfs is currently setup. To be as general as possible, all
partitions are discoverd, of which one will contain the image.

> The trick is to use the 'start_ro' module parameter.
>   echo 1 > /sys/module/md_mod/parameters/start_ro
> 
> Then md will start arrays assuming read-only.  No resync will be
> started, no superblock will be written.  They stay this way until the
> first write at which point they become normal read-write and any
> required resync starts.
> 
> So you can start arrays 'readonly', and resume off a raid1 without any
> risk of the the resync starting when it shouldn't.
> 
> It is probably best to 'echo 0 > ' once you have committed to a
> normal boot, but it isn't really critical.

This is very good to know. I think we can work out something with the
debian-maintainer based on this.

> > 
> > The debian-maintainer of mdadm thinks that the suspend process should
> > have left the array in a clean state, but this is IMHO impossible.
> 
> It probably would be best if suspend left the process in a clean
> state.  It shouldn't be too hard, but it needs to be done in the
> kernel.
> However it isn't critical to all of this working well.
> 
> I mentioned above that if swap in on raid5 it might be awkward.  This
> is because raid5 caches some data that is on disk.  If you snapshot
> the raid5 memory, then resume raid5 so it can write to disk, when you
> come back from suspend you could have old data in the cache.  It
> should be possible to fix this, but it is currently a potential
> problem that might be worth warning people against.

OK, if we can support suspend and raid and even with swap on raid0 or
raid1, I'm happy.

Thanks for the input.

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2disk and raid

2007-04-03 Thread Tim Dijkstra
Hi,

I've got a bugreport [0] from a user trying to use raid and uswsusp. He's
using initramfs-tools available in debian. I'll describe the problem
and my analysis, maybe you can comment on what you think. A warning: I only
have a casual understanding of raid, never looked at any code related to it.

This is a setup where root maybe on raid, but swap isn't. Swap on raid
will be very difficult to support, I think.

When s2disk is started, nothing special is done to the array. It may be
in an unclean state (just like filesystems). Image is written to disk.

After the power cycle the kernel boots, devices are discovered, among
which the ones holding raid. Then we try to find the device that holds
swap in case of resume and / in case of a normal boot.

Now comes a crucial point. The script that finds the raid array, finds
the array in an unclean state and starts syncing.

After this, resume finds an image in the swap partition and starts the
resume process. Part of this process is freezing everything but itself,
which fails on the process/thread that does the syncing.

IMO, the problem comes from the fact we started syncing, before we could
start resume. 

Now the problem could theoretically be solved by not starting the
assembly of the array once it is discovered, but modifying the 
initramfs to do the assembly after we have had the chance to resume.

The debian-maintainer of mdadm thinks that the suspend process should
have left the array in a clean state, but this is IMHO impossible. We
are freezing userspace. A mdamd process looking after the array will
probably get into trouble if we come back from suspend and we have
done something to the array in the mean time.

What do you think?

grts Tim

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415441


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] pass down argv[0] to error messages

2007-04-03 Thread Tim Dijkstra
On Tue, 3 Apr 2007 11:25:23 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> This is a RFC, i am not sure if printing the program name in all error
> messages is really useful, or if just "suspend:" is better there, but
> at least in usage() it should be the correct one.

I think I would vote for not printing the program name at all in the
informational messages, only in the error messages. But I haven't given
it much thought and really don't care much;) If we do want to print
something there, I do want to have the argv[0] there, not suspend, else
it would be a bit confusing.

A few small points:

Maybe you can fix the message on line suspend.c:187 too?


> Index: suspend.c
> ===
> RCS file: /cvsroot/suspend/suspend/suspend.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 suspend.c
> --- suspend.c 1 Apr 2007 22:03:29 -   1.73
> +++ suspend.c 2 Apr 2007 16:14:53 -
> @@ -51,7 +51,7 @@
>  
>  #define suspend_error(msg, args...) \
>  do { \
> - fprintf(stderr, "suspend: " msg " Reason: %m\n", ## args); \
> + fprintf(stderr, "%s: " msg " Reason: %m\n", my_name, ## args); \
>  } while (0);

What is this do { } while (0); thing good for?
  

> @@ -733,8 +734,8 @@ static void suspend_shutdown(int snapsho
>   } else if (use_platform_suspend) {
>   int ret = platform_enter(snapshot_fd);
>   if (ret < 0)
> - fprintf(stderr, "suspend: pm_ops->enter returned"
> - " error %d, calling power_off\n", errno);
> + fprintf(stderr, "%s: pm_ops->enter returned error "
> + "%d, calling power_off\n", my_name, errno);
>   }

Can't you use the suspend_error macro here?

>  
> @@ -773,13 +774,13 @@ int suspend_system(int snapshot_fd, int 
>   if (use_platform_suspend) {
>   int ret = platform_prepare(snapshot_fd);
>   if (ret < 0) {
> - fprintf(stderr, "suspend: pm_ops->prepare returned "
> - "error %d\n", errno);
> + fprintf(stderr, "%s: pm_ops->prepare returned error "
> + "%d\n", my_name, errno);
>   use_platform_suspend = 0;
>   }
>   }

And here?

  


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-04-03 Thread Tim Dijkstra
On Tue, 3 Apr 2007 00:39:04 +0200
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> Hi all !
> 
> Thanks to Alan Stern's help on usb-devel list, I have a working
> suspend-to-disk. My USB issues seem to have gone away thanks to his
> patch.

That is good news.

> I need to unload (resp. reload) some modules before (resp. after)
> suspending, in order to avoid a lockup after resuming (no prompt, and
> limit keyboard possibilities). So I configured hibernate script to use
> s2disk and added to the hibernate blacklist the modules leading to a
> lockup.

This is a nice workaround (and I guess you're happy you can finally
hibernate, but this means there are bugs in these modules. You (sh|c)ould
file a bug or try to contact the maintainers of these modules so they
can fix it.

> Now I can fully use s2disk. I even tried to abort the suspension using
> backspace. It worked. For the moment, I tested only in text mode (no X
> running).

s2disk will change virtual terminals before suspending, so chances are
good that it will from X too.

If you still feel like experimenting, maybe you can try Johannes` patches
for suspend to ram, and see if s2both now works OK too?

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2ram style options for s2both v2

2007-04-02 Thread Tim Dijkstra
Hi,

I polished the patch a bit. I found one additional problem; also `-s'
was already in use by both s2disk and s2ram. This let me to decide not
to allow any short options for the `s2ram hacks' in s2both. For s2ram
they are still supported. If however we would start using the usage
function from config.c for s2ram too, they will not show up. This is
maybe a good thing even.

OK to commit?

Index: s2ram.c
===
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.51
diff -u -r1.51 s2ram.c
--- s2ram.c 16 Mar 2007 15:03:08 -  1.51
+++ s2ram.c 2 Apr 2007 11:29:25 -
@@ -25,10 +25,10 @@
 static struct pci_dev vga_dev;
 static struct pci_access *pacc;
 /* Flags set from whitelist */
-static int flags, vbe_mode = -1;
+static int flags = 0, force = 0, vbe_mode = -1;
 char bios_version[1024], sys_vendor[1024], sys_product[1024], 
sys_version[1024];
 
-/* return codes for s2ram_prepare */
+/* return codes for s2ram_is_supported */
 #define S2RAM_OK   0
 #define S2RAM_FAIL 1
 #define S2RAM_NOFB 126
@@ -229,18 +229,21 @@
return 0;
 }
 
-int s2ram_prepare(void)
+int s2ram_is_supported(void)
 {
-   int ret, id;
+   int ret = 0, id;
 
-   dmi_scan();
-   id = machine_match();
-   ret = s2ram_check(id);
-
-   if (ret)
-   return ret;
+   if (flags && !force) {
+   printf("acpi_sleep, vbe_save, vbe_post, radeontool and pci_save"
+   " parameter must be used with --force\n\n");
+   return EINVAL;
+   }
 
-   ret = s2ram_hacks();
+   if (!force) {
+   dmi_scan();
+   id = machine_match();
+   ret = s2ram_check(id);
+   } 
 
return ret;
 }
@@ -299,6 +302,43 @@
}
 }
 
+void s2ram_add_flag(int opt, const char *opt_arg)
+{
+   /* The characters are the `deprecated' short options. They will not
+* clash with the new labels untill we reach quirk 65... */
+   switch (opt) {
+   case 1:
+   case 'f':
+   force = 1;
+   break;
+   case 2:
+   case 's':
+   flags |= VBE_SAVE;
+   break;
+   case 3:
+   case 'p':
+   flags |= VBE_POST;
+   break;
+   case 4:
+   case 'm':
+   flags |= VBE_MODE;
+   break;
+   case 5:
+   case 'r':
+   flags |= RADEON_OFF;
+   break;
+   case 6:
+   case 'v':
+   flags |= PCI_SAVE;
+   break;
+   case 7:
+   case 'a':
+   flags |= (atoi(optarg) & (S3_BIOS | S3_MODE));
+   break;
+
+   }
+}
+
 #ifndef CONFIG_BOTH
 static void usage(void)
 {
@@ -328,23 +368,17 @@
 
 int main(int argc, char *argv[])
 {
-   int i, id = -1, ret = 0, test_mode = 0, force = 0;
+   int i, id = -1, ret = 0, test_mode = 0;
int active_console = -1;
struct option options[] = {
{ "test",   no_argument,NULL, 'n'},
{ "help",   no_argument,NULL, 'h'},
-   { "force",  no_argument,NULL, 'f'},
-   { "vbe_save",   no_argument,NULL, 's'},
-   { "vbe_post",   no_argument,NULL, 'p'},
-   { "vbe_mode",   no_argument,NULL, 'm'},
-   { "radeontool", no_argument,NULL, 'r'},
{ "identify",   no_argument,NULL, 'i'},
-   { "acpi_sleep", required_argument,  NULL, 'a'},
-   { "pci_save",   no_argument,NULL, 'v'},
+   HACKS_LONG_OPTS
{ NULL, 0,  NULL,  0 }
};
 
-   while ((i = getopt_long(argc, argv, "nhfspmriva:", options, NULL)) != 
-1) {
+   while ((i = getopt_long(argc, argv, "nhi" "fspmrva:", options, NULL)) 
!= -1) {
switch (i) {
case 'h':
usage();
@@ -356,48 +390,27 @@
case 'n':
test_mode = 1;
break;
-   case 'f':
-   force = 1;
-   break;
-   case 's':
-   flags |= VBE_SAVE;
-   break;
-   case 'p':
-   flags |= VBE_POST;
-   break;
-   case 'm':
-   flags |= VBE_MODE;
-   break;
-   case 'r':
-   flags |= RADEON_OFF;
-   break;
-   case 'a':
-   flags |= (atoi(optarg) & (S3

Re: [Suspend-devel] s2both on powerpc

2007-04-01 Thread Tim Dijkstra
On Sun, 01 Apr 2007 10:15:22 +0200
Johannes Berg <[EMAIL PROTECTED]> wrote:

> On Sat, 2007-03-31 at 22:17 +0200, Tim Dijkstra wrote:
> 
> > Hmm, ok I misunderstood then. I thought that in our previous tests
> > you said it used echo mem ... maybe you were using your patches;)
> 
> Yes, I do of course run my patches. "Eat your own dogfood" ;)
> 
> > That would maybe explain why s2both doesn't work yet for cedric.
> > s2both works through an ioctl on /dev/snapshot, which is equivalent
> > (Rafael tells me) to echo mem ...
> > s2ram (with my patch) uses /dev/pmu first, then tries echo mem ...
> 
> I thought s2both was patched too.

That was the initial idea, so I added the /dev/pmu stuff to s2ram. I
misunderstood however how s2both uses the bits from s2ram. Rafael/Pavel
added a ioctl to /dev/snapshot to trigger suspend to state s3, this
uses more or less the same code as echo mem...
So after you told me (or I thought you told me;) that echo mem ...
should be working OK on modern kernels, I thought s2both would work OK.

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-31 Thread Tim Dijkstra
Johannes Berg schreef:
> On Sat, 2007-03-31 at 21:08 +0200, Tim Dijkstra wrote:
>
>> And to ask your earlier question, s2both uses something slightly
>> different
>> than s2ram. s2ram tries first some ioctl on /dev/pmu, if that fails it
>> tries
>> echo mem > /sys/power/state.
>>
>> Johannes told me these two should be more or less the same, I'm not
>> sure if this already the case on a 2.6.18 kernel. Any idea?
>
> Definitely not, the latter (echo mem ...) is only available in kernels
> with a few patches I have pending for .22 :)

> Previously, echo mem ... doesn't work at all on powerpc.

Hmm, ok I misunderstood then. I thought that in our previous tests
you said it used echo mem ... maybe you were using your patches;)

That would maybe explain why s2both doesn't work yet for cedric.
s2both works through an ioctl on /dev/snapshot, which is equivalent
(Rafael tells me) to echo mem ...
s2ram (with my patch) uses /dev/pmu first, then tries echo mem ...


grts Tim


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-31 Thread Tim Dijkstra
Cédric Boutillier schreef:
> Hi !


Cedric gets a `colorful' screen and no suspend when using
echo mem > /s/p/s, but using the ioctl on /dev/pmu works OK


>
> On 3/30/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>> Which version of the suspend utilities do you use?
>
> Well, I do not know exactly what you mean by "suspend utilities" but I
> am using kernel 2.6.18.

He is using the version I asked him to test. It is recent CVS with my ppc
patch on top.

And to ask your earlier question, s2both uses something slightly different
than s2ram. s2ram tries first some ioctl on /dev/pmu, if that fails it
tries
echo mem > /sys/power/state.

Johannes told me these two should be more or less the same, I'm not
sure if this already the case on a 2.6.18 kernel. Any idea?

grts Tim




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-30 Thread Tim Dijkstra
On Fri, 30 Mar 2007 12:41:11 +0200
Johannes Berg <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-03-30 at 11:27 +0200, Tim Dijkstra wrote:
> > On Sat, 24 Mar 2007 21:16:52 +0100
> > Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > 
> > We're trying to debug s2disk/s2both on somebody else his powerpc, there
> > we had to fix something even before he could write the image to disk,
> > that got me puzzled a bit... Is your machine maybe 64bit or so?
> 
> No, just 32-bit. What did you have to fix? Maybe I fixed it
> unintentionally when fixing a few compilation errors?
> 

Basically this:

Index: suspend.c
===
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.70
diff -u -r1.70 suspend.c
--- suspend.c   16 Mar 2007 16:02:22 -  1.70
+++ suspend.c   29 Mar 2007 19:42:43 -
@@ -207,8 +207,13 @@
swap.dev = blkdev;
swap.offset = offset;
error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
+   /* We cast blkdev to `unsigned long' here because dev_t can be
+* `unsinged long long' on some architectures. The kernel side expects
+* a unsigned long however (32 bits is enough). Without the cast this
+* goes OK on LE, on BE however we end up with the wrong bits...
+*/
if (error && !offset)
-   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
+   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, (unsigned 
long)(blkdev));

return error;
 }


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-29 Thread Tim Dijkstra
Op Thu, 29 Mar 2007 23:54:13 +0200
schreef "Rafael J. Wysocki" <[EMAIL PROTECTED]>:

> Okay, so the patch works.  Tim, if you don't mind, I'd like to apply
> this one.

Sure, go ahead. If I read it right the cast is now done when calling
set_swap_file().

> 
> 
> > > ---
> > >  suspend.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Index: suspend/suspend.c
> > > ===
> > > --- suspend.orig/suspend.c
> > > +++ suspend/suspend.c
> > > @@ -199,7 +199,7 @@ static inline int free_swap_pages(int de
> > > return ioctl(dev, SNAPSHOT_FREE_SWAP_PAGES, 0);
> > >  }
> > >
> > > -static inline int set_swap_file(int dev, dev_t blkdev, loff_t
> > > offset) +static inline int set_swap_file(int dev, u_int32_t
> > > blkdev, loff_t offset) {
> > > struct resume_swap_area swap;
> > > int error;
> > >
> > 
> 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] encourage the usage of --long_options

2007-03-29 Thread Tim Dijkstra
Op Thu, 29 Mar 2007 21:58:10 +0200
schreef Stefan Seyfried <[EMAIL PROTECTED]>:

> > 2) Also pass the short option string to usage and check for each
> > `val' if it is included in the short option string. At first I
> > thought this was a bit overkill, but thinking about it, it is more
> > correct...
> 
> ... this is also fine with me (and since you already have done the
> work... :-)
> 
> > Untested...
> 
> tested by me. No. It doesn't apply (whitespace damaged) and after i
> fixed that up, it did not compile.
> 
> > What do you think?
> 
> It does not work :-)

That is because I didn't change the places which call the usage
function, it was just a `heh, does this sound reasonable' piece 
of code... but here is a working patch:

Index: config.c
===
RCS file: /cvsroot/suspend/suspend/config.c,v
retrieving revision 1.7
diff -u -r1.7 config.c
--- config.c10 Nov 2006 00:08:33 -  1.7
+++ config.c29 Mar 2007 21:11:36 -
@@ -104,16 +104,23 @@
return error;
 }
 
-void usage(char *my_name, struct option *options)
+void usage(char *my_name, struct option *options, const char *short_options)
 {
struct option *opt;
 
-   printf("Usage: %s ", my_name);
-   for (opt = options; opt->name; opt++)
+   printf("Usage: %s\t", my_name);
+   for (opt = options; opt->name; opt++) 
+   {
+   if (strchr(short_options,opt->val))
+   printf("[-%c|--%s", opt->val, opt->name);
+   else
+   printf("[--%s", opt->name);
+
if (opt->has_arg)
-   printf("[-%c <%s>]", opt->val, opt->name);
+   printf(" <%s>]\n\t\t", opt->name);
else
-   printf("[-%c]", opt->val);
+   printf("]\n\t\t");
+   }
 
-   printf(" []\n");
+   printf("[]\n");
 }
Index: config.h
===
RCS file: /cvsroot/suspend/suspend/config.h,v
retrieving revision 1.4
diff -u -r1.4 config.h
--- config.h7 Nov 2006 21:13:33 -   1.4
+++ config.h29 Mar 2007 21:11:36 -
@@ -21,6 +21,6 @@
 
 int parse(char *my_name, char *file_name, int parc, struct config_par *parv);
 
-void usage(char *my_name, struct option options[]);
+void usage(char *my_name, struct option options[], const char *short_options);
 
 #define CONFIG_FILE"/etc/suspend.conf"
Index: resume.c
===
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.41
diff -u -r1.41 resume.c
--- resume.c16 Mar 2007 16:02:22 -  1.41
+++ resume.c29 Mar 2007 21:11:36 -
@@ -746,11 +746,12 @@
char *conf_name = CONFIG_FILE;
int set_off = 0;
unsigned long long int off = 0;
+   const char *optstring = "hf:o:";
 
-   while ((i = getopt_long(argc, argv, "hf:o:", options, NULL)) != -1) {
+   while ((i = getopt_long(argc, argv, optstring, options, NULL)) != -1) {
switch (i) {
case 'h':
-   usage("resume", options);
+   usage("resume", options, optstring);
exit(EXIT_SUCCESS);
case 'f':
conf_name = optarg;
@@ -760,7 +761,7 @@
set_off = 1;
break;
default:
-   usage("resume", options);
+   usage("resume", options, optstring);
return -EINVAL;
}
}
Index: suspend.c
===
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.71
diff -u -r1.71 suspend.c
--- suspend.c   27 Mar 2007 10:54:19 -  1.71
+++ suspend.c   29 Mar 2007 21:11:36 -
@@ -1182,11 +1187,12 @@
unsigned long long int off = 0;
int set_size = 0;
unsigned long int im_size = 0;
+   const char *optstring="hf:s:o:";
 
-   while ((i = getopt_long(argc, argv, "hf:s:o:", options, NULL)) != -1) {
+   while ((i = getopt_long(argc, argv, optstring, options, NULL)) != -1) {
switch (i) {
case 'h':
-   usage("suspend", options);
+   usage("suspend", options, optstring);
exit(0);
case 'f':
conf_name = optarg;
@@ -1200,7 +1206,7 @@
set_off = 1;
break;
default:
-   usage("suspend", options);
+   usage("suspend", options, optstring);
return -EINVAL;
}
}


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay

Re: [Suspend-devel] s2both on powerpc

2007-03-29 Thread Tim Dijkstra
On Thu, 29 Mar 2007 00:28:07 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Thursday, 29 March 2007 00:14, Tim Dijkstra wrote:
> > On Tue, 27 Mar 2007 23:11:41 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > > diff -u -r1.70 suspend.c
> > > > --- suspend.c   16 Mar 2007 16:02:22 -  1.70
> > > > +++ suspend.c   27 Mar 2007 20:36:52 -
> > > > @@ -208,7 +208,7 @@
> > > > swap.offset = offset;
> > > > error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
> > > > if (error && !offset)
> > > > -   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
> > > > +   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, (unsigned 
> > > > long) blkdev);  
> > > 
> > > Heh, I wonder. :-)
> > 
> > 
> > Apparently it worked... IMHO this means the code in user.c should be
> > different. snapshot_ioctl expects an unsigned long, which isn't what 
> > the user sends. Would it be useful to use copy_from_user()? (Disclaimer
> > I haven't written a single line of kernel code yet, this is just from
> > reading user.c)
> 
> Well, maybe, but then we'd have to redefine the ioctl which I'd rather avoid.
> Besides, the kernel only needs the lower 32 bits anyway, so why should we
> complicate things to pass the remaining 32 zero bits to it for nothing?
> 
> The problem is that in fact the kernel expects us to provide a _pointer_
> as arg to the ioctl and unsigned long just happens to be of the same size.  So
> I think we can live with your hack in the userland just fine (but please add a
> comment explaining why its needed).

Would this comment suffice?

Index: suspend.c
===
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.70
diff -u -r1.70 suspend.c
--- suspend.c   16 Mar 2007 16:02:22 -  1.70
+++ suspend.c   29 Mar 2007 19:42:43 -
@@ -207,8 +207,13 @@
swap.dev = blkdev;
swap.offset = offset;
error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
+   /* We cast blkdev to `unsigned long' here because dev_t can be
+* `unsinged long long' on some architectures. The kernel side expects
+* a unsigned long however (32 bits is enough). Without the cast this
+* goes OK on LE, on BE however we end up with the wrong bits...
+*/
if (error && !offset)
-   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
+   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, (unsigned 
long)(blkdev));

return error;
 }


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] encourage the usage of --long_options

2007-03-29 Thread Tim Dijkstra
On Thu, 29 Mar 2007 14:30:04 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 29, 2007 at 11:04:22AM +0200, Tim Dijkstra wrote:
> > On Thu, 29 Mar 2007 10:32:59 +0200
> > Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> > 
> > > This is ugly and long, but shows the long options (we could leave out
> > > the short options, or go for something like:
> > > Usage: suspend  [-h|--help]
> > > [-f|--config ]
> > > [-s|--image_size ]
> > > [-o|--resume_offset ]
> > > []
> > 
> > I would go for this.
> 
> ok, this is

> Index: config.c
> ===
> RCS file: /cvsroot/suspend/suspend/config.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 config.c
> --- config.c  10 Nov 2006 00:08:33 -  1.7
> +++ config.c  29 Mar 2007 12:29:04 -
> @@ -108,12 +108,12 @@ void usage(char *my_name, struct option 
>  {
>   struct option *opt;
>  
> - printf("Usage: %s ", my_name);
> + printf("Usage: %s\t", my_name);
>   for (opt = options; opt->name; opt++)
>   if (opt->has_arg)
> - printf("[-%c <%s>]", opt->val, opt->name);
> + printf("[-%c|--%s <%s>]\n\t\t", opt->val, opt->name, 
> opt->name);
>   else
> - printf("[-%c]", opt->val);
> + printf("[-%c|--%s]\n\t\t", opt->val, opt->name);
>  
> - printf(" []\n");
> + printf("[]\n");
>  }
> 
> 
> Objections, anyone?

Sorry, to change my mind on this;) But if we want to support only
'--force' and no short option for it this doesn't fit. I can leave out
the short option from the short option string, but the option struct for
`--force' needs an `val', and per code above, it will show in usage().

Is see two ways out. 
1) drop all short options form usage()
2) Also pass the short option string to usage and check for each `val'
if it is included in the short option string. At first I thought this was
a bit overkill, but thinking about it, it is more correct...



Index: config.c
===
RCS file: /cvsroot/suspend/suspend/config.c,v
retrieving revision 1.7
diff -u -r1.7 config.c
--- config.c10 Nov 2006 00:08:33 -  1.7
+++ config.c29 Mar 2007 19:26:47 -
@@ -104,16 +104,23 @@
return error;
 }

-void usage(char *my_name, struct option *options)
+void usage(char *my_name, struct option *options, char *short_options)
 {
struct option *opt;

-   printf("Usage: %s ", my_name);
-   for (opt = options; opt->name; opt++)
+   printf("Usage: %s\t", my_name);
+   for (opt = options; opt->name; opt++)
+   {
+   if (strchr(short_options,opt->val))
+   printf("[-%c|--%s", opt->val, opt->name);
+   else
+   printf("[--%s", opt->name);
+
if (opt->has_arg)
-   printf("[-%c <%s>]", opt->val, opt->name);
+   printf(" <%s>]\n\t\t", opt->name);
else
-   printf("[-%c]", opt->val);
+   printf("]\n\t\t");
+   }

-   printf(" []\n");
+   printf("[]\n");
 }


Untested...

What do you think?

grts Tim



signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-29 Thread Tim Dijkstra
On Thu, 29 Mar 2007 11:37:52 +0200
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:


> I have not seen any message from resume. I unpacked the initramfs
> using your script: everything seems in place:

> ./etc/uswsusp.conf

And has the same contents as the one in your regular /-partition, right?
Just checking the obvious;)

To narrow the problem down a bit further, could you make sure that in
your /etc/uswsusp.conf you have:

shutdown method = poweroff

And try s2disk instead of s2both and report what happens?

Also could you type this (as root):

dd count=10c if=/dev/hda3

After you have got your system in the colorful screen state after
s2both?

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] encourage the usage of --long_options

2007-03-29 Thread Tim Dijkstra
On Thu, 29 Mar 2007 10:32:59 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> This is ugly and long, but shows the long options (we could leave out
> the short options, or go for something like:
> Usage: suspend  [-h|--help]
> [-f|--config ]
> [-s|--image_size ]
> [-o|--resume_offset ]
> []

I would go for this.

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Fw: Bug#416475: Samsung Q35 is not in the whitelist : workaround

2007-03-28 Thread Tim Dijkstra
Hi,

Any further question to Jérémie before we can add it to the whitelist?

grts Tim

Jérémie Delaitre op Wed, 28 Mar 2007 10:57:30 +0200

 

Package: uswsusp
Version: 0.6~cvs20070202-1

The Samsung Q35 is not in the whitelist of s2ram but is working with :

s2ram -f -a 3

s2ram -i returns :

This machine can be identified by:
sys_vendor   = "SAMSUNG ELECTRONICS CO., LTD."
sys_product  = "Q35/Q36"
sys_version  = "04SD"
bios_version = "04SD"



signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-28 Thread Tim Dijkstra
On Tue, 27 Mar 2007 23:11:41 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> > diff -u -r1.70 suspend.c
> > --- suspend.c   16 Mar 2007 16:02:22 -  1.70
> > +++ suspend.c   27 Mar 2007 20:36:52 -
> > @@ -208,7 +208,7 @@
> > swap.offset = offset;
> > error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
> > if (error && !offset)
> > -   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
> > +   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, (unsigned long) 
> > blkdev);  
> 
> Heh, I wonder. :-)


Apparently it worked... IMHO this means the code in user.c should be
different. snapshot_ioctl expects an unsigned long, which isn't what 
the user sends. Would it be useful to use copy_from_user()? (Disclaimer
I haven't written a single line of kernel code yet, this is just from
reading user.c)

static int snapshot_ioctl(struct inode *inode, struct file *filp,
  unsigned int cmd, unsigned long arg)
{

.
.
.


case SNAPSHOT_SET_SWAP_FILE:
if (!data->bitmap) {
/*
 * User space encodes device types as two-byte values,
 * so we need to recode them
 */
if (old_decode_dev(arg)) {
data->swap = swap_type_of(old_decode_dev(arg),
0, NULL);
if (data->swap < 0)
error = -ENODEV;
} else {
data->swap = -1;
error = -EINVAL;
}
} else {
error = -EPERM;
}
break;


grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-28 Thread Tim Dijkstra
Hi Cédric,

On Wed, 28 Mar 2007 23:03:12 +0200
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> When I reboot after having executed s2both, I see the following message:
> "Invalidating stale suspend image" or something similar (I cannot find
> it in the logs though). I don't know if this helps understanding what
> happens.

That is probably swapon that found an image on disk and invalidates it.
This means that you indeed got an image on disk.

Did you see any messages from resume? I guess you didn't else resume
would have restored the swap signature. Do you have resume
and /etc/uswsusp.conf on your initramfs? You can unpack it with the
little script I attached.

As stefan said be careful with your data! You shouldn't try to reboot
after a failed s2both before you have restored the swap partition
'swapon '.

What did you exactly do? You started s2both, got a colorful screen and
typed reboot via ssh?

Can you try to start s2both when logged from a different computer and
see if you can get the error code it returns?

grts Tim



unpack-initramfs
Description: Binary data


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-27 Thread Tim Dijkstra
On Tue, 27 Mar 2007 21:18:17 +0200
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> Hi !
> 
> Tim said:
> > Apparently it should be an `unsigned long long', which would make
> > printf("blkdev: %llu \n", blkdev); the correct way to print it.
> 
> héhé ! I got a non zero result !!! Thanks Tim ! (Should I be happy ? :) )

Maybe. 

> $sudo s2both
> suspend: resume_dev = 268462812
> blkdev: 771
> suspend: Could not use the resume device (try swapon -a)
> zsh: exit 22sudo s2both

I hadn't noticed that Rafael had let you print out the exact same
number (resume_dev), but with a different specifier (%lu). He thought
that dev_t is unsigned long, while on your arch it is unsigned long long.

Well I haven't done the math, but apparently, if we cast print out the
ull number 771 in BE as an ul number we get 268462812.

Now the problem is that the kernel (just like Rafael) expects an
unsigned long. I think we better fix this in the kernel, but can you
try if this works (I must confess I don't now if this makes sense):




diff -u -r1.70 suspend.c
--- suspend.c   16 Mar 2007 16:02:22 -  1.70
+++ suspend.c   27 Mar 2007 20:36:52 -
@@ -208,7 +208,7 @@
swap.offset = offset;
error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
if (error && !offset)
-   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
+   error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, (unsigned long) 
blkdev);

return error;
 }


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-27 Thread Tim Dijkstra
On Tue, 27 Mar 2007 13:23:44 +0200
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> Hi !
> 
> > Apparently, resume_dev = 268462812 before calling set_swap_file().
> > I've no idea where these 0:0 come from, but I do have idea why it doesn't
> > work.  I don't know how to fix that right now, though.
> >
> > Greetings,
> > Rafael
> 
> The fact that I got 0:0 might come from the fact that I am far from
> being an expert in coding. I don't know if the technique I use to
> print out blkdev is correct. I just saw that there was a macro in
> linux/kdev_t.h to sprintf dev_t objects. I just mimicked this to write
> the line. If it turns out that this is not the good way, please tell
> me and I will try what you propose.

Well, I'm also quite new to this game;)

Apparently it should be an `unsigned long long', which would make
printf("blkdev: %llu \n", blkdev); the correct way to print it.

grts Tim



signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2ram style options for s2both

2007-03-27 Thread Tim Dijkstra
Hi,

I think we agree that it would be nice for s2both to have the same
commandline options as s2ram. Well, here is a patch;) A few comments:

The logic I choose for s2both is to continue with suspend-to-disk
in case of an error in the s2ram part. Even if the problem is with cli
options. This is how it was until know...

To minimize duplication, I moved some things around in s2ram. Only
the option string is duplicated now. We could of course do a 
s2ram_get_optstring function...

I changed the short option for s2both/s2disk --config,
which currently is -f to -c, so we can use -f for --force. This of
course breaks stefan his scripts;)

I could add `force' to the flags,
#define S2RAM_FORCE 0x8000
flags |= S2RAM_FORCE;

etc. Seems cleaner, but maybe you don't like it...

Index: s2ram.c
===
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.51
diff -u -r1.51 s2ram.c
--- s2ram.c 16 Mar 2007 15:03:08 -  1.51
+++ s2ram.c 27 Mar 2007 12:18:20 -
@@ -25,7 +25,7 @@
 static struct pci_dev vga_dev;
 static struct pci_access *pacc;
 /* Flags set from whitelist */
-static int flags, vbe_mode = -1;
+static int flags = 0, force = 0, vbe_mode = -1;
 char bios_version[1024], sys_vendor[1024], sys_product[1024], 
sys_version[1024];
 
 /* return codes for s2ram_prepare */
@@ -229,18 +229,21 @@
return 0;
 }
 
-int s2ram_prepare(void)
+int s2ram_prepare(void)
 {
-   int ret, id;
+   int ret = 0, id;
 
-   dmi_scan();
-   id = machine_match();
-   ret = s2ram_check(id);
-
-   if (ret)
-   return ret;
+   if (flags && !force) {
+   printf("acpi_sleep, vbe_save, vbe_post and radeontool parameter 
"
+  "must be used with --force\n\n");
+   return EINVAL;
+   }
 
-   ret = s2ram_hacks();
+   if (!force) {
+   dmi_scan();
+   id = machine_match();
+   ret = s2ram_check(id);
+   }
 
return ret;
 }
@@ -299,6 +302,33 @@
}
 }
 
+void s2ram_add_flag(int opt, const char *opt_arg)
+{
+   switch (opt) {
+   case 's':
+   flags |= VBE_SAVE;
+   break;
+   case 'p':
+   flags |= VBE_POST;
+   break;
+   case 'm':
+   flags |= VBE_MODE;
+   break;
+   case 'r':
+   flags |= RADEON_OFF;
+   break;
+   case 'a':
+   flags |= (atoi(optarg) & (S3_BIOS | S3_MODE));
+   break;
+   case 'v':
+   flags |= PCI_SAVE;
+   break;
+   case 'f':
+   force = 1;
+   break;
+   }
+}
+
 #ifndef CONFIG_BOTH
 static void usage(void)
 {
@@ -328,7 +358,7 @@
 
 int main(int argc, char *argv[])
 {
-   int i, id = -1, ret = 0, test_mode = 0, force = 0;
+   int i, id = -1, ret = 0, test_mode = 0;
int active_console = -1;
struct option options[] = {
{ "test",   no_argument,NULL, 'n'},
@@ -356,48 +386,27 @@
case 'n':
test_mode = 1;
break;
-   case 'f':
-   force = 1;
-   break;
-   case 's':
-   flags |= VBE_SAVE;
-   break;
-   case 'p':
-   flags |= VBE_POST;
-   break;
-   case 'm':
-   flags |= VBE_MODE;
-   break;
-   case 'r':
-   flags |= RADEON_OFF;
-   break;
-   case 'a':
-   flags |= (atoi(optarg) & (S3_BIOS | S3_MODE));
-   break;
-   case 'v':
-   flags |= PCI_SAVE;
+   case '?':
+   usage();
break;
default:
-   usage();
+   s2ram_add_flag(i,optarg);
break;
}
}
-   if (flags && !force) {
-   printf("acpi_sleep, vbe_save, vbe_post and radeontool parameter 
"
-  "must be used with --force\n\n");
-   usage();
-   }
+
if (force && test_mode) {
printf("force and test mode do not make sense together.\n\n");
usage();
}
 
-   if (!force) {
-   dmi_scan();
-   id = machine_match();
-   ret = s2ram_check(id);
+   if (test_mode) {
+   machine_known(id);
+   goto out;
}
 
+   ret = s2ram_prepare();
+
if (ret == S2RAM_UNKNOWN) {

[Suspend-devel] ioctl(dev, SNAPSHOT_S2RAM, 0);

2007-03-27 Thread Tim Dijkstra
Hi,

I was just adding some command line options to s2both when I noticed
that in fact it didn't went to s3 anymore. I noticed this before, but
thought that my experimentation with pm-utils was to blams.

Debugging a bit if found out that 
ioctl(dev, SNAPSHOT_S2RAM, 0);

sets errno to EBUSY

s2ram via the binary or echo mem ... works though...

$ uname -a
Linux commensaal 2.6.20 #1 Mon Feb 5 14:06:25 CET 2007 i686 GNU/Linux

Any ideas?

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [Pm-utils] powerpc support

2007-03-27 Thread Tim Dijkstra
Hi Stefan,

Thanks for the comments, I'll integrate them and try to minimize the
number of ifdefs.

On Tue, 27 Mar 2007 13:23:03 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> > +#endif
> > +   case '?':  
> 
> Will probably not work, since it is not in options[] above?

getopts returns ? if an option other than those specified in optstring
are used, that way you can catch invalid options.

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] What did we resume from?

2007-03-27 Thread Tim Dijkstra
On Tue, 27 Mar 2007 12:11:34 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Tuesday, 27 March 2007 11:51, Tim Dijkstra wrote:
> > Hi.
> > 
> > Sometimes it seems relevant for the thing calling s2both to know what
> > route we took in the end, be it s2ram or s2disk.
> > 
> > Would you think returning a value is a suitable way of communicating
> > that to the user? Would some scripts maybe break, because they only
> > expect 0 in case of success?
> 
> I think some scripts could break (Stefan knows better, though).
> 
> What's the exact problem you're trying to solve?

Well, I'm trying to get support for s2both in pm-utils. pm-utils is an
intermediary layer where services and apps can hook into so they can do
`something' when the system suspends/resumes. The `something' maybe
dependent on what state the system came back from.

I must confess, I can't really think of a real use case here, other
than the vbetool stuff that pm-utils tries to do when s2ram is not
there. So maybe it is not worth the trouble...

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] powerpc support

2007-03-27 Thread Tim Dijkstra
On Tue, 27 Mar 2007 11:55:03 +0200
"Luca Tettamanti" <[EMAIL PROTECTED]> wrote:

> On 3/27/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > This is a first cut at supporting powerpc for s2*. For the s2ram bit it
> > basically removes the vbetool code. This has two reasons. First, there
> > isn't a powerpc version of libx86 yet. Second, the machines that have
> > support for s2ram in the kernel don't need those hacks.
> 
> Hum, scattering #ifdef all over the code quickly turns into a
> maintenance nightmare.

Well, yeah, it's not pretty. We do need to rip out most of it. Any
better ideas? Make noop functions for everything we do not have on
powerpc?

grts Tim


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] What did we resume from?

2007-03-27 Thread Tim Dijkstra
Hi.

Sometimes it seems relevant for the thing calling s2both to know what
route we took in the end, be it s2ram or s2disk.

Would you think returning a value is a suitable way of communicating
that to the user? Would some scripts maybe break, because they only
expect 0 in case of success?

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] powerpc support

2007-03-27 Thread Tim Dijkstra
Hi,

This is a first cut at supporting powerpc for s2*. For the s2ram bit it
basically removes the vbetool code. This has two reasons. First, there
isn't a powerpc version of libx86 yet. Second, the machines that have
support for s2ram in the kernel don't need those hacks.

As you noticed, I've asked some people to test it a bit already. The
s2ram part seems to work fine, the s2disk part still has some problems,
which could be related to its BE nature. But this will have to be fixed
anyway.

With this patch people can at least compile and give us some feedback.

grts Tim

Index: s2ram.c
===
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.51
diff -u -r1.51 s2ram.c
--- s2ram.c 16 Mar 2007 15:03:08 -  1.51
+++ s2ram.c 27 Mar 2007 07:55:33 -
@@ -10,14 +10,26 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_PPC
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#endif
 
 #include 
 
 #ifndef S2RAM
 #define S2RAM
 #endif
-#include "vbetool/vbetool.h"
+
 #include "vt.h"
+#ifndef CONFIG_PPC
+#include "vbetool/vbetool.h"
 #include "s2ram.h"
 
 static void *vbe_buffer;
@@ -228,9 +240,13 @@
 
return 0;
 }
+#endif
 
 int s2ram_prepare(void)
 {
+#ifdef CONFIG_PPC
+   return 0;
+#else
int ret, id;
 
dmi_scan();
@@ -243,13 +259,49 @@
ret = s2ram_hacks();
 
return ret;
+#endif
+}
+
+#ifdef CONFIG_PPC
+/* This will be deprecated, but is needed on older kernels (< May 2006) */ 
+int s2ram_do_pmu(void) {
+int ret = 0,  fd;
+unsigned long arg = 0;
+
+if ((fd = open("/dev/pmu", O_RDWR)) < 0) 
+return errno;
+
+ret = ioctl(fd, PMU_IOC_CAN_SLEEP, &arg);
+
+if (!ret && arg != 1) 
+ret = ENOTSUP;
+
+if (!ret)
+ret = ioctl(fd, PMU_IOC_SLEEP, arg);
+
+close(fd);
+
+   return ret;
 }
+#endif
 
 /* Actually enter the suspend. May be ran on frozen system. */
 int s2ram_do(void)
 {
-   int ret = 0;
-   FILE *f = fopen("/sys/power/state", "w");
+   int ret = 0;
+   FILE *f;
+
+#ifdef CONFIG_PPC
+   ret = s2ram_do_pmu();
+   /* If the PMU says not supported, we better stop here, we could
+* crash the machine on some kernels. On success we return too;) */
+   if (!ret || (ret == ENOTSUP))
+   return ret;
+   /* Else we just continue as if nothing happened, future kernels
+* will work with /s/p/s. */
+   ret = 0;
+#endif
+   f = fopen("/sys/power/state", "w");
if (!f) {
printf("/sys/power/state does not exist; what kind of ninja 
mutant machine is this?\n");
return ENODEV;
@@ -260,6 +322,7 @@
 } 
 
 void s2ram_resume(void)
 {
+#ifndef CONFIG_PPC
if (flags & PCI_SAVE) {
printf("restoring PCI config of device %02x:%02x.%d\n",
vga_dev.bus, vga_dev.dev, vga_dev.func);
@@ -297,6 +351,7 @@
printf("Calling radeon_cmd_light(1)\n");
radeon_cmd_light(1);
}
+#endif
 }
 
 #ifndef CONFIG_BOTH
@@ -306,6 +361,7 @@
   "\n"
   "Options:\n"
   "-h, --help:   this text.\n"
+#ifndef CONFIG_PPC
   "-n, --test:   test if the machine is in the database.\n"
   "  returns 0 if known and supported\n"
   "-i, --identify:   prints a string that identifies the 
machine.\n"
@@ -322,6 +378,7 @@
   "suspend\n"
   "  1=s3_bios, 2=s3_mode, 3=both\n"
   "-v, --pci_save:   save the PCI config space for the VGA 
card.\n"
+#endif
   "\n");
exit(1);
 }
@@ -331,8 +388,8 @@
int i, id = -1, ret = 0, test_mode = 0, force = 0;
int active_console = -1;
struct option options[] = {
-   { "test",   no_argument,NULL, 'n'},
{ "help",   no_argument,NULL, 'h'},
+   { "test",   no_argument,NULL, 'n'},
{ "force",  no_argument,NULL, 'f'},
{ "vbe_save",   no_argument,NULL, 's'},
{ "vbe_post",   no_argument,NULL, 'p'},
@@ -349,6 +406,7 @@
case 'h':
usage();
break;
+#ifndef CONFIG_PPC
case 'i':
dmi_scan();
identify_machine();
@@ -377,11 +435,21 @@
case 'v':
flags |= PCI_SAVE;
break;
+#else 
+   /* For consistency with the non-ppc version, it seems best to 
+* me to accept, but ignore the s2ram 'hacks'. */
default:
+   fprintf(stderr, "The powerpc version of s2ram doe

Re: [Suspend-devel] rip out libx86 build options from the Makefile

2007-03-26 Thread Tim Dijkstra
On Thu, 22 Mar 2007 13:29:15 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> (sending a new mail, so that it does not get lost in the old thread)
> 
> If nobody objects, i will rip out the libx86 build option from the
> Makefile. I will not do this today or tomorrow, but as time permits
> (or if Tim beats me to it, all the better ;-)
> 
> So if somebody thinks this is really useful to leave in, he should speak
> up now (and provide some good arguments).

I've beaten you;)

I also added some words about lib86 and where to get it,

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] Make the error printing more useful (was: s2both on powerpc)

2007-03-26 Thread Tim Dijkstra
On Mon, 26 Mar 2007 11:07:59 +0200
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> after reading this thread, i got the impression that we do not report
> errors verbosely enough. I mean - we normally never see those messages,
> but if we do, due to an error having happened, we always need to start
> adding more debugging printf's before we know what happened.
> 
> Oh, yes, and pm-ops->* can only return -1 or 0, so telling the user
> that it returned "-1" is also pretty pointless, let's tell him whats
> in errno instead.
> 
> So i came up with this one, comments are appreciated:

Looks good and very usefull!

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] s2both on powerpc

2007-03-24 Thread Tim Dijkstra
On Sun, 25 Mar 2007 00:17:22 +0100
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> > Which kernel are you using? Could you try to catch the error code that
> > s2both returns? Or just add two printf's that print out the error code?
> 
> I have modified the three lines you mentionned as follows:
> error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
> printf("Error: errno = %d\n", errno);
> if (error && !offset) {
> error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
> printf("Error: errno = %d\n", errno);
> }
> 
> After having rebuild and reinstalled the package, I get the followind 
> messsage :
> $ sudo s2both
> Error: errno = 25

ENOTTY, That is to be expected from 2.6.18, there isn't support yet for
SNAPSHOT_SET_SWAP_AREA

> Error: errno = 22
> suspend: Could not use the resume device (try swapon -a)
> zsh: exit 22sudo s2both

OK, that is EINVAL. Reading the kernel source, it seems it can't 
decode the value that represents the device we're sending to the kernel. 
I don't understand ... 
 
> I am using debian kernel 2.6.18-4 (version  2.6.18.dfsg.1-11)

> I would be happy to do more testing, with precise instructions.

Could you print out `blkdev'? Just to be sure, could you send the output of 
ls -l /dev/hda3 ?

thanks Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2both on powerpc -- another one

2007-03-24 Thread Tim Dijkstra
On Fri, 23 Mar 2007 14:40:02 +0100
Johannes Berg <[EMAIL PROTECTED]> wrote:

> Hi Tim,
> 
> I gave it a try now...
> 
> Here are a few things:
>  - compression is totally messed up on my machine, it writes about 8% of
>the image and then gets an -ENOSPC error from the compression
>algorithm (I put printk's into the kernel and it doesn't come from
>the kernel)

OK, have to see what liblzf claims to support. But compression is not
essential, lets first see if we can get it to work without.

>  - resume needs to grow a timeout on the question -- my laptop has USB
>keyboard only and interaction with it isn't possible during boot.

I thought that the kernel had support for that, maybe that is dependent
on your machine... Anyway, I think we can do a timeout.

>  - is it possible to resume an image the kernel wrote, or will resume
>ignore it and I can still use echo ... > /sys/power/resume?

It will ignore it (and vice versa). They both write a sightly different
signature on disk.

>  - on my machine, resume is unable to read the image and prints a huge
>message. I made sure that I'm booting the exact kernel and everything
>so I don't know why it tells me that the image isn't usable.

Hmm, that is a bit disappointing, I had hoped suspend was written clean
enough that it would run on powerpc too...
I don't have that much experience with powerpc, but they are
big-endian, right? 

Judging from what message your get it is mostly likely failing in
init_swap_reader, but that is just a guess. It would help if you could
pinpoint where resume fails. It is not that much code, so if you feel
like it, maybe you could add some printfs;)

I'm adding the suspend-devel list to cc, maybe rafeal or pavel have 
some idea what is most likely to fail on powerpc?

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] s2both on powerpc

2007-03-24 Thread Tim Dijkstra
Hi Cédric,

First of all, thanks for testing! I'm cc-ing the suspend-devel list
maybe they can chime in if they have some idea...


On Fri, 23 Mar 2007 17:03:34 +0100
"Cédric Boutillier" <[EMAIL PROTECTED]> wrote:

> Hi !
> 
> I compiled successfully uswsusp on my iBook (mid 2005), and installed
> the built package. I got the needed s2* binaries in /usr/sbin.
> 
> However, when I typed : "sudo s2both", I got the following message:
> suspend: Could not use the resume device (try swapon -a).
> 
> Here is the content of /etc/uswsusp.conf. /dev/hda3 is my swap partition.
> 
> # /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both
> resume device = /dev/hda3
> compress = y
> early writeout = y
> image size = 486993182
> RSA key file = /etc/uswsusp.key
> shutdown method = platform
> 
> Any idea ?

Well if your swap partition was up and running that means that one of
two ioctl's failed. 

error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
if (error && !offset)
error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);

Which kernel are you using? Could you try to catch the error code that
s2both returns? Or just add two printf's that print out the error code?

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-22 Thread Tim Dijkstra
On Tue, 20 Mar 2007 23:53:37 +0100
Tim Dijkstra <[EMAIL PROTECTED]> wrote:

> On Tue, 20 Mar 2007 22:43:37 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > Hm, well.  I think that if we don't ship something, we should not have the
> > option to compile it in our Makefile.
> > 
> > Instead, we should update the documentation to tell the users that they
> > should obtain the thing separately and what to do to get everything right.
> 
> Well than we agree;)

So I remove all of it from the Makefile and updated the docs.

OK?

Index: HOWTO
===
RCS file: /cvsroot/suspend/suspend/HOWTO,v
retrieving revision 1.18
diff -u -r1.18 HOWTO
--- HOWTO   2 Feb 2007 12:10:26 -   1.18
+++ HOWTO   22 Mar 2007 12:39:31 -
@@ -15,9 +15,10 @@
 
 crw-r--r--  1 root root 10, 231 Jan 13 21:21 /dev/snapshot
 
-(e) [optionally] Marc Lehmann's libLZF library (for image compression)
-(f) [optionally] libgcrypt (for image encryption)
-(g) [optionally] libsplashy (for user space splash)
+(e) libx86, a hardware-independent library for executing real-mode x86 code
+(f) [optionally] Marc Lehmann's libLZF library (for image compression)
+(g) [optionally] libgcrypt (for image encryption)
+(h) [optionally] libsplashy (for user space splash)
 
 2) Basic steps
 
@@ -41,7 +42,23 @@
 The kernel installation procedure will depend on what Linux distribution
 you use and should be documented elsewhere.
 
-(b) [optionally] Install the Marc Lehmann's libLZF library
+(b) Install libx86 developement packages
+
+If libx86 is not installed on your system (Debian: libx86-dev) you can download
+the tarball from http://www.codon.org.uk/~mjg59/libx86/downloads/. Unpack it,
+change into the resulting directory. Then run
+
+$ make
+
+or if you're building for an x86_64 
+
+$ make BACKEND=x86emu
+
+Next, become root and run
+
+# make install DESTDIR=/usr/local
+
+(c) [optionally] Install the Marc Lehmann's libLZF library
 
 If you want to use the image compression functionality and libLZF it's not
 installed on your system, download the tarball from
@@ -58,7 +75,7 @@
 [This will put the lzf.h file into /usr/local/include, the library
 into /usr/local/lib, and the lzf binary into /usr/local/bin.]
 
-(c) [optionally] Install libgrypt
+(d) [optionally] Install libgrypt
 
 If you want to use the image encryption functionality of the suspend
 tools, you'll need libgcrypt to build them.  If you have installed
Index: Makefile
===
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.52
diff -u -r1.52 Makefile
--- Makefile16 Mar 2007 15:03:08 -  1.52
+++ Makefile22 Mar 2007 12:39:31 -
@@ -3,7 +3,6 @@
 #CONFIG_SPLASHY=yes
 #CONFIG_UDEV=yes
 #CONFIG_RESUME_DYN=yes
-#CONFIG_EMBEDDED_LIBX86=yes
 
 SUSPEND_DIR=/usr/local/sbin
 RESUME_DIR=/usr/local/lib/suspend
@@ -20,17 +19,13 @@
 CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
 LD_FLAGS=-L/usr/local/lib
 
-ifdef CONFIG_EMBEDDED_LIBX86
-CC_FLAGS += -Ilibx86/
-endif
-
 BINARIES=s2disk s2both s2ram swap-offset resume
 BINARIES_MIN=s2disk swap-offset
 
-S2RAM_OBJ=vt.o vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o
+S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
 SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 
 
-S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz
+S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86
 SWSUSP_LD_FLAGS = $(LD_FLAGS)
 
 ifndef CONFIG_RESUME_DYN
@@ -70,25 +65,17 @@
 STATIC_CC_FLAGS=$(shell directfb-config --cflags)\
$(shell pkg-config --static --cflags glib-2.0)
 endif
+ifdef CONFIG_RESUME_DYN
+SWSUSP_LD_FLAGS += -lgcc_s
 endif
-
-###
-ifdef CONFIG_EMBEDDED_LIBX86
-ifeq ($(ARCH), x86_64)
-LIBX86_MAKE = BACKEND=x86emu
 endif
 
-S2RAM_OBJ += libx86/libx86.a 
-else
-S2RAM_LD_FLAGS += -lx86
-endif
 
-all: $(BINARIES)
 
-clean:
-   make -C libx86 clean || true
-   rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o
+all: $(BINARIES) 
 
+clean: 
+   rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o
 
  Rules for objects
 s2ram-both.o: s2ram.c s2ram.h whitelist.c
@@ -101,21 +88,13 @@
$(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@
 
 # Simple objects with header
-config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/x86-common.o 
vbetool/vbetool.o: %.o : %.c %.h
+config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/vbetool.o: %.o : 
%.c %.h
$(CC) $(CC_FLAGS) -c $< -o $@
 
 # Simple object without header
 dmidecode.o radeontool.o : %.o: %.c
$(CC) $(CC_FLAGS) -c $< -o $@
 
-libx86/libx86.a:
-   ln -sf lrmi.h libx86/libx86.h
-   make -C libx86 $(LIBX86_MAKE) static
-
-libx86/lrmi.o libx86/thunk.o: %.o: %.c
-   $(CC) $(CC_FLAGS) -c $< -o $@
-
-
 #

Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-20 Thread Tim Dijkstra
On Tue, 20 Mar 2007 22:43:37 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> Hm, well.  I think that if we don't ship something, we should not have the
> option to compile it in our Makefile.
> 
> Instead, we should update the documentation to tell the users that they
> should obtain the thing separately and what to do to get everything right.

Well than we agree;)
 
> The static linking is possible in either case, isn't it?

Yes sure, I would think dynamic linking would work as well, but we can
document that they should call something 'make static' or so.

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] ioctl(snaptshot_fd, SNAPSHOT_S2RAM, 0);

2007-03-20 Thread Tim Dijkstra
On Tue, 20 Mar 2007 16:38:43 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:

> On Tue 2007-03-20 11:37:36, Tim Dijkstra wrote:
> > Hi,
> > 
> > I just noticed I have misunderstood how the machine is put in S3 for
> > s2both. I thought it would use a function from s2ram.c to do that, but
> > it seems it uses 
> > ioctl(snaptshot_fd, SNAPSHOT_S2RAM, 0);
> > 
> > Just to be sure, this will probably do precisely the same thing as echo
> > 'mem > /sys/power/state', or not?
> 
> Not _precisely_. It avoids running freezer because processes are
> already frozen.

OK, to get concrete, I'm investigating if we can get s2both for
powerpc.  Johannes Berg tells me that on most 32bit apple laptops 'echo
mem > /sys/power/state' does what it is supposed to. Does this mean that
ioctl(snaptshot_fd, SNAPSHOT_S2RAM, 0); will do too? I can just ask
people to try that out of course... or I could dive in the kernel code,
but asking the experts is easier;)

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] ioctl(snaptshot_fd, SNAPSHOT_S2RAM, 0);

2007-03-20 Thread Tim Dijkstra
Hi,

I just noticed I have misunderstood how the machine is put in S3 for
s2both. I thought it would use a function from s2ram.c to do that, but
it seems it uses 
ioctl(snaptshot_fd, SNAPSHOT_S2RAM, 0);

Just to be sure, this will probably do precisely the same thing as echo
'mem > /sys/power/state', or not?

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-20 Thread Tim Dijkstra
On Tue, 20 Mar 2007 08:56:45 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 19, 2007 at 10:21:16PM +0100, Rafael J. Wysocki wrote:
> > > I can't see how people can `depend' on it. Especially since this is
> > > only in CVS since a few days. Also libx86 isn't in CVS anymore so they
> > > will have to get it anyway. The only difference is that instead of
> > > typing two times cd XXX and make && make install, they only do that once.
> > 
> > Hm, I think I misunderstood the issue.
> > 
> > Can anyone please explain to me what the current situation is and why it may
> > be a good idea to change it (or not)?
> 
> One problem people might hit is that, depending on the distro packaging, they
> might pick up libx86 with x86emu enabled, even though they run on x86 hardware
> (which should, in theory, work just fine, but well, you never know).

This would then be a bug in the packaging of the distro then.

> Another possible problem might be dynamic linking vs static linking. Up to
> now we always linked x86emu objects directly into s2ram. Dynamically linking
> against system wide installed libx86 might turn up new bugs. The "embedded"
> libx86 stuff in the Makefile does static linking.

I don't think this would matter much, but heh, I lack the the knowledge too ;)

> These are the main points why i did it as it is, to avoid any regressions.
> I personally, probably simply from lack of knowledge ;-) don't have a strong
> opinion on how to do it "right".

I'm not claiming that I've did it right, but I've made a patch that
changes the Makefile a bit to make it more 'clean'. Could you take a
look if you approve it. It is in the reply to Rafael.

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-19 Thread Tim Dijkstra
On Mon, 19 Mar 2007 22:21:16 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> Hm, I think I misunderstood the issue.
> 
> Can anyone please explain to me what the current situation is and why it may
> be a good idea to change it (or not)?

libx86 is a dependency of vbetool. Since the new release of vbetool it
is split of in a different library, packaged in a different tarball. We
probably wont be doing much development on libx86 so Stefan purged that
part from CVS. People compiling will now need to get the tarball from
Matthews website.

So far so good. 

Now I would argue: let people just get that tarball, unpack, type make
&& make install, just like they would for liblzf or libgcrypt.
Stefan however, has implemented a hack to help people compile suspend
in one go. You know can unpack the tarball, make a symlink and type
make.

I was arguing that was unnecessary, and would just clutter our makefile.

Well, I'm not going to get religious over this, I made a patch that
keeps stefans idea, but makes it a bit better to read (IMHO), it also 
makes it a bit easier to add other CONFIG_EMBEDDED_ stuff and will help 
with my ppc-support patch that I will send in a few days.
I also removed some cruft left over from the pre-libx86 days.

OK, to commit?

grts Tim



Index: Makefile
===
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.52
diff -u -r1.52 Makefile
--- Makefile16 Mar 2007 15:03:08 -  1.52
+++ Makefile19 Mar 2007 22:28:13 -
@@ -20,19 +20,25 @@
 CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
 LD_FLAGS=-L/usr/local/lib
 
-ifdef CONFIG_EMBEDDED_LIBX86
-CC_FLAGS += -Ilibx86/
-endif
-
 BINARIES=s2disk s2both s2ram swap-offset resume
 BINARIES_MIN=s2disk swap-offset
 
-S2RAM_OBJ=vt.o vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o
+S2RAM_OBJ=vt.o vbetool/vbetool.o radeontool.o dmidecode.o
 SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 
 
-S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz
+S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz -lx86
 SWSUSP_LD_FLAGS = $(LD_FLAGS)
 
+ifeq ($(ARCH), x86_64)
+LIBX86_MAKE = BACKEND=x86emu
+endif
+
+ifdef CONFIG_EMBEDDED_LIBX86
+CC_FLAGS += -Ilibx86/
+S2RAM_LD_FLAGS += -Llibx86/
+subdirs += libx86
+endif
+
 ifndef CONFIG_RESUME_DYN
 STATIC_LD_FLAGS = -static
 endif
@@ -70,25 +76,28 @@
 STATIC_CC_FLAGS=$(shell directfb-config --cflags)\
$(shell pkg-config --static --cflags glib-2.0)
 endif
+ifdef CONFIG_RESUME_DYN
+SWSUSP_LD_FLAGS += -lgcc_s
 endif
-
-###
-ifdef CONFIG_EMBEDDED_LIBX86
-ifeq ($(ARCH), x86_64)
-LIBX86_MAKE = BACKEND=x86emu
 endif
 
-S2RAM_OBJ += libx86/libx86.a 
-else
-S2RAM_LD_FLAGS += -lx86
-endif
 
-all: $(BINARIES)
 
-clean:
-   make -C libx86 clean || true
-   rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o
+all: $(subdirs) $(BINARIES) 
 
+clean: 
+   rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o
+   rm -f libx86/libx86.h
+   for dir in $(subdirs); do \
+   $(MAKE) -C $$dir clean; \
+   done
+
+$(subdirs):
+   $(MAKE) -C $@
+
+libx86:
+   $(MAKE) $(LIBX86_MAKE) -C $@ static
+   -ln -s lrmi.h libx86/libx86.h 
 
  Rules for objects
 s2ram-both.o: s2ram.c s2ram.h whitelist.c
@@ -101,21 +110,13 @@
$(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@
 
 # Simple objects with header
-config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/x86-common.o 
vbetool/vbetool.o: %.o : %.c %.h
+config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/vbetool.o: %.o : 
%.c %.h
$(CC) $(CC_FLAGS) -c $< -o $@
 
 # Simple object without header
 dmidecode.o radeontool.o : %.o: %.c
$(CC) $(CC_FLAGS) -c $< -o $@
 
-libx86/libx86.a:
-   ln -sf lrmi.h libx86/libx86.h
-   make -C libx86 $(LIBX86_MAKE) static
-
-libx86/lrmi.o libx86/thunk.o: %.o: %.c
-   $(CC) $(CC_FLAGS) -c $< -o $@
-
-
  Rules for binaries
 s2disk:$(SWSUSP_OBJ) suspend.c
$(CC) -g $(CC_FLAGS)  $^ -o $@ $(SWSUSP_LD_FLAGS)
@@ -169,3 +170,4 @@
 install: $(patsubst %,install-%,$(BINARIES)) $(SNAPSHOT) install-conf
 
 
+.PHONY: clean $(subdirs) install install-minimal install-resume-on-initrd 
install-resume-new-initrd $(patsubst %,install-%,$(BINARIES))

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-19 Thread Tim Dijkstra
On Mon, 19 Mar 2007 11:27:50 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Monday, 19 March 2007 08:28, Stefan Seyfried wrote:
> > On Sun, Mar 18, 2007 at 04:25:21PM +0100, Tim Dijkstra wrote:
> > > On Wed, 14 Mar 2007 16:05:40 +0100
> > > Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> > > 
> > > Sorry I didn't respond to this earlier...
> > >  
> > > > I removed all the removed x86emu files from the inlined patch, they are
> > > > included in the attached bzip'ed diff
> > > 
> > > X86emu is no longer present in CVS right? Why do we then not just tell
> > 
> > Correct.
> > 
> > > people to get the tarball and install it? Just like for the other libs?
> > 
> > Well, it seems libx86 is not too common among distributions right now.
> > And it makes it easier to compile for Pavel ;-)
> >  
> > > This CONFIG_EMBEDDED_LIBX86 just clutters our makefile...
> > 
> > I don't care too much about one way or the other. I think it is not too
> > bad and it might make it easier for people to compile stuff by themselves.
> > 
> > But if there is a general consensus about that, i have no problem with
> > removing it.
> 
> Please don't.  Some current users may depend on it.

I can't see how people can `depend' on it. Especially since this is
only in CVS since a few days. Also libx86 isn't in CVS anymore so they
will have to get it anyway. The only difference is that instead of
typing two times cd XXX and make && make install, they only do that once.

But if this is a sensitive point because Pavel likes it, I'll stop
arguing about it;)

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] move to vbetool-1.0

2007-03-18 Thread Tim Dijkstra
On Wed, 14 Mar 2007 16:05:40 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

Sorry I didn't respond to this earlier...
 
> I removed all the removed x86emu files from the inlined patch, they are
> included in the attached bzip'ed diff

X86emu is no longer present in CVS right? Why do we then not just tell
people to get the tarball and install it? Just like for the other libs?

This CONFIG_EMBEDDED_LIBX86 just clutters our makefile...

Just my 0.02€ 

grts Tim

> Index: Makefile
> ===
> RCS file: /cvsroot/suspend/suspend/Makefile,v
> retrieving revision 1.51
> diff -u -p -r1.51 Makefile
> --- Makefile  15 Feb 2007 09:37:17 -  1.51
> +++ Makefile  14 Mar 2007 14:50:29 -
> @@ -3,6 +3,7 @@
>  #CONFIG_SPLASHY=yes
>  #CONFIG_UDEV=yes
>  #CONFIG_RESUME_DYN=yes
> +#CONFIG_EMBEDDED_LIBX86=yes
>  
>  SUSPEND_DIR=/usr/local/sbin
>  RESUME_DIR=/usr/local/lib/suspend
> @@ -19,6 +20,10 @@ ARCH:=$(shell uname -m)
>  CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
>  LD_FLAGS=-L/usr/local/lib
>  
> +ifdef CONFIG_EMBEDDED_LIBX86
> +CC_FLAGS += -Ilibx86/
> +endif
> +
>  BINARIES=s2disk s2both s2ram swap-offset resume
>  BINARIES_MIN=s2disk swap-offset
>  
> @@ -28,12 +33,6 @@ SWSUSP_OBJ=vt.o md5.o encrypt.o config.o
>  S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci -lz
>  SWSUSP_LD_FLAGS = $(LD_FLAGS)
>  
> -ifeq ($(ARCH), x86_64)
> -S2RAM_OBJ+=vbetool/thunk.o vbetool/x86emu/libx86emu.a 
> -else
> -S2RAM_OBJ+=vbetool/lrmi.o
> -endif
> -
>  ifndef CONFIG_RESUME_DYN
>  STATIC_LD_FLAGS = -static
>  endif
> @@ -73,16 +72,25 @@ STATIC_CC_FLAGS=$(shell directfb-config 
>  endif
>  endif
>  
> +###
> +ifdef CONFIG_EMBEDDED_LIBX86
> +ifeq ($(ARCH), x86_64)
> +LIBX86_MAKE = BACKEND=x86emu
> +endif
> +
> +S2RAM_OBJ += libx86/libx86.a 
> +else
> +S2RAM_LD_FLAGS += -lx86
> +endif
> +
>  all: $(BINARIES)
>  
>  clean:
> - rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o 
> vbetool/x86emu/*.o vbetool/x86emu/*.a
> + make -C libx86 clean || true
> + rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o
>  
>  
>   Rules for objects
> -vbetool/x86emu/libx86emu.a:
> - make -C vbetool/x86emu -f makefile.linux
> -
>  s2ram-both.o: s2ram.c s2ram.h whitelist.c
>   $(CC) $(CC_FLAGS) -DCONFIG_BOTH -c $< -o $@
>  
> @@ -97,7 +105,14 @@ config.o vt.o bootsplash.o splash.o spla
>   $(CC) $(CC_FLAGS) -c $< -o $@
>  
>  # Simple object without header
> -vbetool/lrmi.o vbetool/thunk.o dmidecode.o radeontool.o : %.o: %.c
> +dmidecode.o radeontool.o : %.o: %.c
> + $(CC) $(CC_FLAGS) -c $< -o $@
> +
> +libx86/libx86.a:
> + ln -sf lrmi.h libx86/libx86.h
> + make -C libx86 $(LIBX86_MAKE) static
> +
> +libx86/lrmi.o libx86/thunk.o: %.o: %.c
>   $(CC) $(CC_FLAGS) -c $< -o $@
>  
>  


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Switch to VBETool 1.0 codebase

2007-03-05 Thread Tim Dijkstra
On Mon, 5 Mar 2007 12:44:22 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> ;-) So let's do a poll: what distributions already include libx86 as a
> package?

/me raises hand

Debian has, that is probably related to the fact that Matthew is a
debian developer...

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Switch to VBETool 1.0 codebase

2007-03-05 Thread Tim Dijkstra
Hi,

Our diff to VBETool 1.0 is virtually non-existent, the only
'significant' change is the do_get_mode / __get_mode change.
Can't we persuade Matthew to take these changes? than we can just point
at vbetool code and drop it from out repository.

Then maybe I can persuade him to create a vbetool-dev package so
uswsusp can compile against it in debian.

But then there is this very important question mark;)

> - fprintf(stderr, "Function not supported\n");
> + fprintf(stderr, "Function not supported?\n");

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [PATCH] Switch to VBETool 1.0 codebase

2007-03-05 Thread Tim Dijkstra
On Mon, 5 Mar 2007 12:03:18 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 05, 2007 at 11:35:10AM +0100, Arkadiusz Miskiewicz wrote:
> > On Monday 05 of March 2007, Stefan Seyfried wrote:
> > 
> > > Note: this patch will not compile right now, you'll need to unpack libx86
> > > into ./libx86 inside the suspend source.
> > 
> > Why libpci is not included within suspend, same for zlib, lzf, gpg-error, 
> > gcrypt? Leave it externall :)
> 
> Yes, i also thought about that. OTOH it is another _uncommon_ dependency.
> And you basically need it to build (you don't need liblzf, zlib only if you
> have a recent libpci, ... :-)
> And my favourite distro does not (yet) ship it ;-)

I don't find this really convincing arguments, but I guess you know that;)

Last time I checked we also had to patch the source a bit to make it
work from within suspend. But maybe this has changed?

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] [patch] small trivial "make install" fixes

2007-02-14 Thread Tim Dijkstra
On Wed, 14 Feb 2007 12:33:24 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> i need these for a chrooted build (where $DESTDIR is not always present
> before make install):
> 
> 
> --- Makefile
> +++ Makefile
> @@ -137,10 +137,10 @@
>   fi
>  
>  install-resume:
> - install --mode=755 resume $(DESTDIR)$(RESUME_DIR)
> + install -D --mode=755 resume $(DESTDIR)$(RESUME_DIR)/resume
>  
>  install-% : %
> - install --mode=755 $< $(DESTDIR)$(SUSPEND_DIR)
> + install -D --mode=755 $< $(DESTDIR)$(SUSPEND_DIR)/$<
>  
>  # Some convenience targets
>  install-resume-new-initrd:   resume conf/$(CONFIGFILE)
> 
> 
> If nobody has some serious objections, i'll commit these soon (saves me a
> local patch :-)

Seems good to me.

I already wondered who added all those -Ds in the old Makefile;)

But now in the new one you only need two.

grts TIm

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Failure to resume from suspend to disk

2007-02-14 Thread Tim Dijkstra
On Wed, 14 Feb 2007 18:08:27 +0100
Christian Axelsson <[EMAIL PROTECTED]> wrote:

> Stefan Seyfried wrote:
> > On Wed, Feb 14, 2007 at 05:28:00PM +0100, Christian Axelsson wrote:
> >> Hello!
> >>
> >> Im trying to resume from disk om my dell 420 but after suspending (using 
> >> s2disk) and passing resume=/dev/hda1 the kernel just boots as normal and 
> >> then pass control over to normal init AND my swap-space is corrupt 
> >> afterwards. Am I missing something obvious...?
> > 
> > Yes. You need to setup your initrd to call the resume binary with apropriate
> > options or with a matching config file.
> > 
> > Usually the distribution does set this up for you, but there are maybe some
> > out there that are not up to date wrt. that.
> > 
> > The resume= kernel parameter is pretty meaningless for s2disk :-)
> 
> Ah that explains alot :)
> Is there any sample general initrd-scripts out there that I can use as a 
> base? (maybe this is the wrong place to ask though, sorry if that is the 
> case :)

Read the HOWTO and README please.

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Bug#410320: s2ram: whitelist entry

2007-02-12 Thread Tim Dijkstra
Hi Guys,

I just got this report

On Fri, 9 Feb 2007 18:19:59 +0100
Bill Allombert <[EMAIL PROTECTED]> wrote:

> Package: uswsusp
> Version: 0.3~cvs20060928-6
> Severity: wishlist
> 
> Hello Tim,
> 
> With etch-amd64 on my new laptop, s2ram work fine with that option:
> 
> #s2ram -f -a 1
> 
> Here the laptop ID:
> 
> #This machine can be identified by:
> sys_vendor   = "FUJITSU SIEMENS"
> sys_product  = "Amilo Si 1520"
> sys_version  = "Rev 1"
> bios_version = " 1.10"

Current CVS already has this entry:

 { "FUJITSU SIEMENS","Amilo Si 1520","", "", 
S3_BIOS|S3_MODE },

I'm not really an expert in those video hacks. What would Bill have
missed without S3_MODE? Higher resolution console maybe?

grts Tim


signature.asc
Description: PGP signature
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] suspend on ppc /w pmu

2007-02-07 Thread Tim Dijkstra
Hi Guys,

At the moment we support only ix86_{32,64} machines. I personally do
not have a ppc machine, but apparently bringing it in a s2ram state is
pretty easy. It is something along the lines of:

fd = open("/dev/pmu", O_RDWR);

ioctl(fd, PMU_IOC_SLEEP, arg);

If we integrate this into the s2ram binary, we can also support s2both
for them.

Maybe you have more thoughts about it, being the power-management gurus
you are... What do you think?

grts Tim

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Using a swap file

2007-02-03 Thread Tim Dijkstra
On Sat, 3 Feb 2007 23:52:18 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Saturday, 3 February 2007 23:10, Tim Dijkstra wrote:
> > Hi,
> > 
> > I'm testing to see if I can suspend/resume using a swap file. I have
> > created a swap file on one of my (lvm) partitions and have the
> > the following lines in my config file (which I got with swap-offset):
> > 
> > resume device = /dev/mapper/vg_cs-local
> > resume offset = 12979490
> > 
> > s2disk refuses to suspend however, because in the function
> > 
> > static inline int set_swap_file(int dev, dev_t blkdev, loff_t offset)
> > .
> > .
> > error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
> > 
> > Sets errno to 25.
> 
> This is ENOTTY, so it means that the kernel doesn't implement the call.

Yes, that's what I figured. 

> > This is on a 2.6.19.2 kernel btw. Am I doing something wrong?
> 
> Sorry, my fault (memory doesn't serve me right, apparently).  The support
> for swap files will be included in 2.6.20 for the first time.  Currently it's
> only in -mm and -rc kernels.

OK, no problem. That's what I thought, I was a bit to lazy to grep to
the changelog;)

grts Tim

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Using a swap file

2007-02-03 Thread Tim Dijkstra
Hi,

I'm testing to see if I can suspend/resume using a swap file. I have
created a swap file on one of my (lvm) partitions and have the
the following lines in my config file (which I got with swap-offset):

resume device = /dev/mapper/vg_cs-local
resume offset = 12979490

s2disk refuses to suspend however, because in the function

static inline int set_swap_file(int dev, dev_t blkdev, loff_t offset)
.
.
error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);

Sets errno to 25.

This is on a 2.6.19.2 kernel btw. Am I doing something wrong?

grts Tim

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] What kernel has support for ...?

2007-02-02 Thread Tim Dijkstra
On Fri, 2 Feb 2007 13:28:16 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> > > b) Platform mode instead  
> > 
> > I'm not sure what you mean here ...  
> 
> i guess it is SNAPSHOT_PMOPS...
> >

Ah, yes. The 'instead' is a remnant of a larger sentence that I cut out
saying something like 'instead of halt'.

grts Tim

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] What kernel has support for ...?

2007-02-02 Thread Tim Dijkstra
Hi,

Could someone please tell me what (stable) kernels have support for:

a) Suspend/Resume with swap files
b) Platform mode instead

And is there a easy way to test for swap file support, some /sys entry
perhaps?

Thanks,

Tim

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] New Makefile

2007-01-31 Thread Tim Dijkstra
Hi,

Here is my shot at a new Makefile. What do you think?

grts Tim


===



#CONFIG_COMPRESS=yes
#CONFIG_ENCRYPT=yes
#CONFIG_SPLASHY=yes
#CONFIG_UDEV=yes
#CONFIG_RESUME_DYN=yes

SUSPEND_DIR=/usr/local/sbin
RESUME_DIR=/usr/local/lib/suspend
CONFIG_DIR=/etc
RESUME_DEVICE=
BOOT_DIR=/boot
CONFIGFILE=suspend.conf
CFLAGS := -O2 -Wall

###

ARCH:=$(shell uname -m)

CC_FLAGS=-I/usr/local/include -DS2RAM $(CFLAGS)
LD_FLAGS=-L/usr/local/lib

BINARIES=s2disk s2both s2ram swap-offset resume
BINARIES_MIN=s2disk swap-offset

S2RAM_OBJ=vt.o vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o
SWSUSP_OBJ=vt.o md5.o encrypt.o config.o loglevel.o splash.o bootsplash.o 

S2RAM_LD_FLAGS = $(LD_FLAGS) -lpci
SWSUSP_LD_FLAGS = $(LD_FLAGS)

ifeq ($(ARCH), x86_64)
S2RAM_OBJ+=vbetool/thunk.o vbetool/x86emu/libx86emu.a 
else
S2RAM_OBJ+=vbetool/lrmi.o
endif

ifndef CONFIG_RESUME_DYN
STATIC_LD_FLAGS = -static
endif

ifdef CONFIG_COMPRESS
CC_FLAGS+= -DCONFIG_COMPRESS
SWSUSP_LD_FLAGS += -llzf
endif

ifdef CONFIG_ENCRYPT
BINARIES+= suspend-keygen 
BINARIES_MIN+= suspend-keygen 
CC_FLAGS+= -DCONFIG_ENCRYPT
GCRYPT_CC_FLAGS = $(shell libgcrypt-config --cflags)
SWSUSP_CC_FLAGS += $(GCRYPT_CC_FLAGS)
GCRYPT_LD_FLAGS = $(shell libgcrypt-config --libs)
SWSUSP_LD_FLAGS += $(GCRYPT_LD_FLAGS)
INSTALL_KEYGEN  = install-keygen
endif

ifndef CONFIG_UDEV
SNAPSHOT=$(DESTDIR)/dev/snapshot
endif

ifdef CONFIG_SPLASHY
SWSUSP_OBJ  += splashy_funcs.o 
CC_FLAGS+= -DCONFIG_SPLASHY
SWSUSP_LD_FLAGS += -lsplashy
ifndef CONFIG_RESUME_DYN
STATIC_LD_FLAGS += -lsplashycnf \
$(shell directfb-config  --libs --input=keyboard \
--imageprovider=jpeg,gif,png\
--font=ft2,default) \
$(shell pkg-config --static --libs glib-2.0)
STATIC_CC_FLAGS=$(shell directfb-config --cflags)\
$(shell pkg-config --static --cflags glib-2.0)
endif
endif

all: $(BINARIES)

clean:
rm -f $(BINARIES) suspend-keygen suspend.keys *.o vbetool/*.o 
vbetool/x86emu/*.o vbetool/x86emu/*.a


 Rules for objects
vbetool/x86emu/libx86emu.a:
make -C vbetool/x86emu -f makefile.linux

s2ram-both.o: s2ram.c s2ram.h whitelist.c
$(CC) $(CC_FLAGS) -DCONFIG_BOTH -c $< -o $@

s2ram.o: s2ram.c s2ram.h whitelist.c
$(CC) $(CC_FLAGS) -c $< -o $@

md5.o encrypt.o: %.o : %.c %.h md5.h
$(CC) $(CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c $< -o $@

# Simple objects with header
config.o vt.o bootsplash.o splash.o splashy_funcs.o vbetool/x86-common.o 
vbetool/vbetool.o: %.o : %.c %.h
$(CC) $(CC_FLAGS) -c $< -o $@

# Simple object without header
vbetool/lrmi.o vbetool/thunk.o dmidecode.o radeontool.o : %.o: %.c
$(CC) $(CC_FLAGS) -c $< -o $@


 Rules for binaries
s2disk: $(SWSUSP_OBJ) suspend.c
$(CC) -g $(CC_FLAGS)  $^ -o $@ $(SWSUSP_LD_FLAGS)

s2ram:  $(S2RAM_OBJ) s2ram.o
$(CC) -g $(CC_FLAGS)  $^ -o $@ $(S2RAM_LD_FLAGS)

s2both: $(SWSUSP_OBJ) $(S2RAM_OBJ) s2ram-both.o suspend.c 
$(CC) -g $(CC_FLAGS) -DCONFIG_BOTH  $^ -o $@ $(SWSUSP_LD_FLAGS) 
$(S2RAM_LD_FLAGS)

resume: resume.c $(SWSUSP_OBJ)
$(CC) $(CC_FLAGS) $(STATIC_CC_FLAGS) $(STATIC_LD_FLAGS) 
$(SWSUSP_LD_FLAGS) $^ -o $@ 

swap-offset: swap-offset.c
$(CC) $(CFLAGS) $< -o $@

suspend-keygen:  keygen.c md5.o encrypt.h 
$(CC) $(CC_FLAGS) $(GCRYPT_CC_FLAGS) -DHAVE_INTTYPES_H -DHAVE_STDINT_H 
md5.o $< -o $@ $(LD_FLAGS) $(GCRYPT_LD_FLAGS)




 Install targets
$(SNAPSHOT):
mknod $(SNAPSHOT) c 10 231;

install-conf: conf/$(CONFIGFILE)
if [ -f $(DESTDIR)$(CONFIG_DIR)/$(CONFIGFILE) ]; then \
install --mode=644 conf/$(CONFIGFILE) \
$(DESTDIR)$(CONFIG_DIR)/$(CONFIGFILE).new;\
else \
install -D --mode=644 conf/$(CONFIGFILE) \
$(DESTDIR)$(CONFIG_DIR)/$(CONFIGFILE); \
fi

install-resume:
install --mode=755 resume $(DESTDIR)$(RESUME_DIR)

install-% : %
install --mode=755 $< $(DESTDIR)$(SUSPEND_DIR)

#FIXME, also alter HOWTO!
install-resume-new-initrd:  resume conf/$(CONFIGFILE)
BOOT_DIR=$(DESTDIR)$(BOOT_DIR) ./scripts/create-resume-initrd.sh 
$(RESUME_DEVICE)

install-resume-on-initrd:   resume 
./scripts/install-resume.sh

install-minimal: $(patsubst %,%-install,$(BINARIES_MIN)) $(SNAPSHOT) 
install-conf

install: $(patsubst %,%-install,$(BINARIES)) $(SNAPSHOT) install-conf



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Suspend-devel maili

Re: [Suspend-devel] Cleaning up Makefile

2007-01-25 Thread Tim Dijkstra
On Thu, 25 Jan 2007 19:04:37 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> > Why is it whitelist.c and whitelist.h?  
 /\
forgot a NOT here ---/

> 
> I only have whitelist.c?

I mean it is more a header file, we don't compile it, it is included. I
would think the proper name to call it is: whitelist.h. 

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Cleaning up Makefile

2007-01-25 Thread Tim Dijkstra
Hi,

While adding the loglevel.[ch], I've got a bit annoyed with the
makefile, it has duplication of stuff all over it. I'm planning to
clean it up a bit. Some question before I do that.

Doe any body mind if I rename the target
install-resume => install-resume-on-initrd

and
install-resume-initrd => install-resume-new-initrd

To better reflect what they do?

Why is it whitelist.c and whitelist.h?


Naturally I'll update the howto.


grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] getconsolefd

2007-01-24 Thread Tim Dijkstra
Hi,

I was skimming trough the code some more when I found some more
duplicated code. getconsolefd in vt.c and console_fd suspend.c. The
differences are that console_fd opens like:

  fd = open(fname, O_RDONLY);
   if (fd < 0 && errno == EACCES)
   fd = open(fname, O_WRONLY);

and getconsolefd

fd = open(fnam, O_RDWR);
if (fd < 0)
return -1;

Also getconsolefd tries a bunch of device nodes, while console_fd only
tries /dev/console.

Attached patch makes resume use getconsolefd.

What do you think?

--- suspend.c   2007-01-24 13:43:55.0 +0100
+++ suspend.c   2007-01-24 14:02:54.0 +0100
@@ -828,26 +828,6 @@
return error;
 }
 
-/**
- * console_fd - get file descriptor for given file name and verify
- * if that's a console descriptor (based on the code of openvt)
- */
-
-static inline int console_fd(const char *fname)
-{
-   int fd;
-   char arg;
-
-   fd = open(fname, O_RDONLY);
-   if (fd < 0 && errno == EACCES)
-   fd = open(fname, O_WRONLY);
-   if (fd >= 0 && (ioctl(fd, KDGKBTYPE, &arg) || (arg != KB_101 && arg != 
KB_84))) {
-   close(fd);
-   return -ENOTTY;
-   }
-   return fd;
-}
-
 #ifndef TIOCL_GETKMSGREDIRECT
 #define TIOCL_GETKMSGREDIRECT  17
 #endif
@@ -867,7 +847,7 @@
struct vt_stat vtstat;
char clear_vt, tiocl[2];
 
-   fd = console_fd("/dev/console");
+   fd = getconsolefd();
if (fd < 0)
return fd;
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Reordering in resume 1/2

2007-01-24 Thread Tim Dijkstra
On Tue, 23 Jan 2007 09:49:27 +
Pavel Machek <[EMAIL PROTECTED]> wrote:

> Hi!
> 
> > This adds some functions to get_kernel_console_loglevel, inspired by
> > those in suspend.c. We could also move parts to a shared file, if
> > desired. 
> 
> Yep, they should move to shared file.

Yes, they were even more equal then I remembered. Well here goes. This
patch introduces loglevel.[ch]

Index: Makefile
===
RCS file: /cvsroot/suspend/suspend/Makefile,v
retrieving revision 1.45
diff -u -r1.45 Makefile
--- Makefile10 Jan 2007 13:24:27 -  1.45
+++ Makefile24 Jan 2007 12:52:19 -
@@ -111,14 +111,14 @@
 splashy_funcs.o: splashy_funcs.c splashy_funcs.h
$(CC) -g $(CFLAGS) $(CC_FLAGS) -c $< -o $@
 
-$(S2DISK): vt.o md5.o encrypt.o config.o suspend.c swsusp.h config.h 
encrypt.h md5.h $(SPLASHOBJ)
-   $(CC) -g $(CFLAGS) $(CC_FLAGS) vt.o md5.o encrypt.o config.o suspend.c 
-o $@ $(SPLASHOBJ) $(LD_FLAGS)
+$(S2DISK): vt.o md5.o encrypt.o config.o loglevel.o suspend.c swsusp.h 
config.h encrypt.h md5.h $(SPLASHOBJ)
+   $(CC) -g $(CFLAGS) $(CC_FLAGS) vt.o md5.o encrypt.o config.o loglevel.o 
suspend.c -o $@ $(SPLASHOBJ) $(LD_FLAGS)
 
-$(S2BOTH): md5.o encrypt.o config.o suspend.c swsusp.h config.h encrypt.h 
md5.h s2ram.c dmidecode.c whitelist.c radeontool.c $(S2RAMOBJ) $(SPLASHOBJ)
-   $(CC) -g $(CFLAGS) -DCONFIG_BOTH $(CC_FLAGS) md5.o encrypt.o config.o 
suspend.c s2ram.c -o $@ $(S2RAMOBJ) $(SPLASHOBJ) $(LD_FLAGS) -lpci
+$(S2BOTH): md5.o encrypt.o config.o loglevel.o suspend.c swsusp.h config.h 
encrypt.h md5.h s2ram.c dmidecode.c whitelist.c radeontool.c $(S2RAMOBJ) 
$(SPLASHOBJ)
+   $(CC) -g $(CFLAGS) -DCONFIG_BOTH $(CC_FLAGS) md5.o encrypt.o config.o 
loglevel.o suspend.c s2ram.c -o $@ $(S2RAMOBJ) $(SPLASHOBJ) $(LD_FLAGS) -lpci
 
-resume:md5.o encrypt.o config.o resume.c swsusp.h config.h encrypt.h 
md5.h $(SPLASHOBJ)
-   $(CC) $(CFLAGS) $(CC_FLAGS) $(STATIC_CC_FLAGS) md5.o encrypt.o config.o 
vt.o resume.c $(SPLASHOBJ) -static -o resume $(LD_FLAGS) $(STATIC_LD_FLAGS)
+resume:md5.o encrypt.o config.o loglevel.o resume.c swsusp.h config.h 
encrypt.h md5.h $(SPLASHOBJ)
+   $(CC) $(CFLAGS) $(CC_FLAGS) $(STATIC_CC_FLAGS) md5.o encrypt.o config.o 
vt.o loglevel.o resume.c $(SPLASHOBJ) -static -o resume $(LD_FLAGS) 
$(STATIC_LD_FLAGS)
 
 swap-offset: swap-offset.c
$(CC) $(CFLAGS) swap-offset.c -o swap-offset
Index: loglevel.c
===
RCS file: loglevel.c
diff -N loglevel.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ loglevel.c  24 Jan 2007 12:52:19 -
@@ -0,0 +1,63 @@
+/* loglevel.c - routines to modify kernel console loglevel
+ *
+ * Released under GPL v2.
+ * (c) 2007 Tim Dijkstra
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+static FILE *printk_file;
+static int proc_mounted = 0;
+
+inline void open_printk(void)
+{
+   struct stat stat_buf;
+   char *procname = "/proc/sys/kernel/printk";
+
+   if (stat(procname, &stat_buf) && errno == ENOENT) {
+   if (mount("none", "/proc", "proc", 0, NULL)) {
+   fprintf(stderr, "resume: Could not mount proc\n");
+   return;
+   } else
+   proc_mounted = 1;
+   }
+
+printk_file = fopen(procname, "r+");
+}
+
+inline int get_kernel_console_loglevel(void)
+{
+int level = -1;
+
+if (printk_file) {
+rewind(printk_file);
+fscanf(printk_file, "%d", &level);
+}
+return level;
+}
+
+inline void set_kernel_console_loglevel(int level)
+{
+if (printk_file) {
+rewind(printk_file);
+fprintf(printk_file, "%d\n", level);
+fflush(printk_file);
+}
+
+}
+
+inline void close_printk(void)
+{
+if (printk_file)
+fclose(printk_file);
+
+   if (proc_mounted)
+   umount("/proc");
+}
+
Index: loglevel.h
===
RCS file: loglevel.h
diff -N loglevel.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ loglevel.h  24 Jan 2007 12:52:19 -
@@ -0,0 +1,10 @@
+/* loglevel.h - routines to modify kernel console loglevel
+ *
+ * Released under GPL v2.
+ * (c) 2007 Tim Dijkstra
+ */
+
+inline void open_printk(void);
+inline int get_kernel_console_loglevel(void);
+inline void set_kernel_console_loglevel(int level);
+inline void close_printk(void);
Index: resume.c
===
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.38
diff -u -r1.38 resume.c
--- resume.c24 Jan 2007 12:41:40 -  1.38
+++ resume.c24 Jan 2007 12

Re: [Suspend-devel] Reordering in resume 2/2

2007-01-23 Thread Tim Dijkstra
On Tue, 23 Jan 2007 13:00:08 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Tuesday, 23 January 2007 10:51, Pavel Machek wrote:
> > Hi!
> > 
> > > Split the opening of resume_dev and retrieval of the header from
> > > read_image into a new function. That way we can do something else if
> > > everything is OK, but there just isn't an image.
> > > The new function return ENOMEDIUM in case of no image, better
> > > suggestions welcome.
> 
> I think EINVAL is also acceptable here.

Well in theory read() could also return a EINVAL, so I can't
distinguish anymore between a failed read and 'no image'.

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


Re: [Suspend-devel] Reordering in resume 0/2

2007-01-23 Thread Tim Dijkstra
On Tue, 23 Jan 2007 10:08:44 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> On Mon, Jan 22, 2007 at 11:43:21PM +0100, Tim Dijkstra wrote:
> > Hi,
> 
> > First patch is somewhat unrelated. While fixing this I was trying to
> > get the logic of read_image(). The last part is unnecessary complex. The
> > if(!error || !ret) should always be true. The only reason I can think
> > of is reboot() failing. This patch just removes that `if' and adds 
> > some protection for a failing reboot();
> 
> This looks sane, maybe for the failed reboot a 
> 
>   while(1)
>   sleep(1);
> 
> construct would be better (i hate busy loops, even if they can never
> happen :-)

If it makes your day, I'll change that for you;)

grts Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


[Suspend-devel] Reordering in resume 2/2

2007-01-22 Thread Tim Dijkstra
Split the opening of resume_dev and retrieval of the header from
read_image into a new function. That way we can do something else if
everything is OK, but there just isn't an image.
The new function return ENOMEDIUM in case of no image, better
suggestions welcome.


diff -u ../suspend-cvs-1/resume.c ./resume.c
--- ../suspend-cvs-1/resume.c   2007-01-15 16:52:19.0 +0100
+++ ./resume.c  2007-01-20 13:57:36.0 +0100
@@ -531,18 +531,12 @@
 }
 #endif
 
-static int read_image(int dev, char *resume_dev_name)
+static int open_resume_dev(char *resume_dev_name, 
+   struct swsusp_header *swsusp_header)
 {
-   static struct swsusp_header swsusp_header;
-   static struct swap_map_handle handle;
-   static unsigned char orig_checksum[16], checksum[16];
-   int fd, ret, error = 0;
-   struct swsusp_info *header = mem_pool;
-   char *buffer = (char *)mem_pool + page_size;
-   unsigned int nr_pages;
unsigned int size = sizeof(struct swsusp_header);
unsigned int shift = (resume_offset + 1) * page_size - size;
-   char c;
+   int fd, ret;
 
fd = open(resume_dev_name, O_RDWR);
if (fd < 0) {
@@ -552,15 +546,34 @@
}
if (lseek(fd, shift, SEEK_SET) != shift)
return -EIO;
-   ret = read(fd, &swsusp_header, size);
+   ret = read(fd, swsusp_header, size);
if (ret == size) {
-   if (memcmp(SWSUSP_SIG, swsusp_header.sig, 10))
-   return -EINVAL;
+   if (memcmp(SWSUSP_SIG, swsusp_header->sig, 10)) {
+   close(fd);
+   return -ENOMEDIUM;
+   }
} else {
-   error = ret < 0 ? ret : -EIO;
+   ret = ret < 0 ? ret : -EIO;
+   return ret;
}
-   if (!error)
-   error = read_area(fd, header, swsusp_header.image, page_size);
+   
+   return fd;
+}
+
+static int read_image(int dev, int fd, struct swsusp_header *swsusp_header)
+{
+   static struct swap_map_handle handle;
+   static unsigned char orig_checksum[16], checksum[16];
+   int ret, error = 0;
+   struct swsusp_info *header = mem_pool;
+   char *buffer = (char *)mem_pool + page_size;
+   unsigned int nr_pages;
+   unsigned int size = sizeof(struct swsusp_header);
+   unsigned int shift = (resume_offset + 1) * page_size - size;
+   char c;
+
+   error = read_area(fd, header, swsusp_header->image, page_size);
+
if (!error) {
if(header->image_flags & IMAGE_CHECKSUM) {
memcpy(orig_checksum, header->checksum, 16);
@@ -686,11 +699,11 @@
}
}
/* Reset swap signature now */
-   memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10);
+   memcpy(swsusp_header->sig, swsusp_header->orig_sig, 10);
if (lseek(fd, shift, SEEK_SET) != shift) {
error = -EIO;
} else {
-   ret = write(fd, &swsusp_header, size);
+   ret = write(fd, swsusp_header, size);
if (ret != size) {
error = ret < 0 ? -errno : -EIO;
fprintf(stderr,
@@ -813,8 +826,9 @@
 {
unsigned int mem_size;
struct stat stat_buf;
-   int dev;
+   int dev, resume_dev;
int n, error, orig_loglevel;
+   static struct swsusp_header swsusp_header;
 
error = get_config(argc, argv);
if (error)
@@ -869,27 +883,41 @@
goto Free;
}
 
-   splash_prepare(&splash, splash_param);
-   splash.progress(5);
 
dev = open(snapshot_dev_name, O_WRONLY);
if (dev < 0) {
error = ENOENT;
goto Free;
}
-   error = read_image(dev, resume_dev_name);
+
+   resume_dev = open_resume_dev(resume_dev_name, &swsusp_header);
+   if (resume_dev == -ENOMEDIUM) {
+   error = 0;
+   goto Close;
+   } else if (resume_dev < 0) {
+   error = -resume_dev;
+   goto Close;
+   }
+
+   splash_prepare(&splash, splash_param);
+   splash.progress(5);
+
+   error = read_image(dev, resume_dev, &swsusp_header);
if (error) {
fprintf(stderr, "resume: Could not read the image\n");
error = -error;
-   goto Close;
+   goto Close_splash;
}
+
if (freeze(dev)) {
error = errno;
fprintf(stderr, "resume: Could not freeze processes\n");
-   goto Close;
+   goto Close_splash;
}
atomic_restore(dev);
unfreeze(dev);
+
+Close_splash:
splash.finish();
 Close:
close(dev);

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opi

[Suspend-devel] Reordering in resume 1/2

2007-01-22 Thread Tim Dijkstra
This adds some functions to get_kernel_console_loglevel, inspired by
those in suspend.c. We could also move parts to a shared file, if
desired. 
Also sets kernel_loglevel back to the original if there were no errors.

--- ../suspend-cvs-1/resume.c   2007-01-15 16:07:41.0 +0100
+++ resume.c2007-01-15 16:47:56.0 +0100
@@ -715,12 +717,13 @@
return error;
 }
 
-static void set_kernel_console_loglevel(int level)
+static FILE *printk_file;
+static int proc_mounted = 0;
+
+static inline void open_printk(void)
 {
-   FILE *file;
struct stat stat_buf;
char *procname = "/proc/sys/kernel/printk";
-   int proc_mounted = 0;
 
if (stat(procname, &stat_buf) && errno == ENOENT) {
if (mount("none", "/proc", "proc", 0, NULL)) {
@@ -729,11 +732,36 @@
} else
proc_mounted = 1;
}
-   file = fopen(procname, "w");
-   if (file) {
-   fprintf(file, "%d\n", level);
-   fclose(file);
-   }
+
+printk_file = fopen(procname, "r+");
+}
+
+static inline int get_kernel_console_loglevel(void)
+{
+int level = -1;
+
+if (printk_file) {
+rewind(printk_file);
+fscanf(printk_file, "%d", &level);
+}
+return level;
+}
+
+static inline void set_kernel_console_loglevel(int level)
+{
+if (printk_file) {
+rewind(printk_file);
+fprintf(printk_file, "%d\n", level);
+fflush(printk_file);
+}
+
+}
+
+static inline void close_printk(void)
+{
+if (printk_file)
+fclose(printk_file);
+
if (proc_mounted)
umount("/proc");
 }
@@ -788,7 +816,7 @@
unsigned int mem_size;
struct stat stat_buf;
int dev;
-   int n, error;
+   int n, error, orig_loglevel;
 
error = get_config(argc, argv);
if (error)
@@ -813,6 +841,10 @@
return error;
}
 
+   open_printk();
+   orig_loglevel = get_kernel_console_loglevel();
+   set_kernel_console_loglevel(suspend_loglevel);
+
while (stat(resume_dev_name, &stat_buf)) {
fprintf(stderr, 
"resume: Could not stat the resume device file '%s'\n"
@@ -830,8 +862,6 @@
resume_dev_name[n] = '\0';
}
 
-   set_kernel_console_loglevel(suspend_loglevel);
-
setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);
 
@@ -865,9 +895,14 @@
splash.finish();
 Close:
close(dev);
-
-   set_kernel_console_loglevel(max_loglevel);
 Free:
+   if (error)
+   set_kernel_console_loglevel(max_loglevel);
+   else if (orig_loglevel >= 0)
+   set_kernel_console_loglevel(orig_loglevel);
+
+   close_printk();
+
free(mem_pool);
 
return error;

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel


  1   2   >