Resume -> higher power drain?

Resume -> higher power drain?

[Nils Faerber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!
I just observed a strange phenomenon on my new T42p (latest BIOS).
I can successfully suspend and resume to and from S3 and S4!
Kernel ist vanilla 2.6.11.8 using ACPI support scripts from the Ubuntu
acpi-support package (removes critical modules, does vbe save and
restore, etc...)
So far very fine and indeed good work.

Before suspend I usually see a power consumption of about 16W including
WLAN, which is nicely low.
But strangely after resume from either S3 or S4 I have see a power
consumption of 19W+. This means ~3W more or in other words, roughly 20%
less runtime.
This is pretty annoying - not a real show-stoppper but it would be nicer
without ;)

I have no idea how to diagnose this. My first guess is that some devices
are not resumed correctly but I have no real idea how for example gather
device states before and after suspend, or other means to diagnose this.

So, if anyone has an idea how I can diagnose this and help this issue to
be solved, let me know. Or is there already a solution floating around?

Thanks!

CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfMhpJXeIURG1qHgRAt/BAKCJezug3PTVtwBwhmXAlowh50V8hQCg3plR
4XsEhFqbj6KggagEH4L0DK4=
=1BGX
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Carl-Daniel Hailfinger]

Hi,

Nils Faerber schrieb:
> I just observed a strange phenomenon on my new T42p (latest BIOS).
> [...]
> Before suspend I usually see a power consumption of about 16W including
> WLAN, which is nicely low.
> But strangely after resume from either S3 or S4 I have see a power
> consumption of 19W+. This means ~3W more or in other words, roughly 20%
> less runtime.

I didn't measure the power consumption of my Samsung P35, but after
resume from S3 it gets hotter under the same load than before suspend.
So I can somewhat confirm your report.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Hendrik Jürgens]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Am Samstag, den 07.05.2005, 15:59 +0200 schrieb Carl-Daniel Hailfinger:
> Hi,
> 
> Nils Faerber schrieb:
> > I just observed a strange phenomenon on my new T42p (latest BIOS).
> > [...]
> > Before suspend I usually see a power consumption of about 16W including
> > WLAN, which is nicely low.
> > But strangely after resume from either S3 or S4 I have see a power
> > consumption of 19W+. This means ~3W more or in other words, roughly 20%
> > less runtime.
> 
> I didn't measure the power consumption of my Samsung P35, but after
> resume from S3 it gets hotter under the same load than before suspend.
> So I can somewhat confirm your report.
> 
I can also confirm this behaviour with my acer tm4002lmi. it also has ja
power consumption ~16W and after resuming it has round about 20W.

-- 
Hendrik Juergens
eMail:  hjuerg-ULHALamj7Vx/+Jgy1241yg@public.gmane.org
ICQ:    #63741909
Jabber: speedbur-70FLm3+D511hl2p70BpVqQ@public.gmane.org
PGP:    http://speedbur.nnga.info/pubkey.asc


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Resume -> higher power drain?

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

Hi,

On Sat, May 07, 2005 at 04:14:56PM +0200, Hendrik Jürgens wrote:
> Am Samstag, den 07.05.2005, 15:59 +0200 schrieb Carl-Daniel Hailfinger:
> > Hi,
> > 
> > Nils Faerber schrieb:
> > > I just observed a strange phenomenon on my new T42p (latest BIOS).
> > > [...]
> > > Before suspend I usually see a power consumption of about 16W including
> > > WLAN, which is nicely low.
> > > But strangely after resume from either S3 or S4 I have see a power
> > > consumption of 19W+. This means ~3W more or in other words, roughly 20%
> > > less runtime.
> > 
> > I didn't measure the power consumption of my Samsung P35, but after
> > resume from S3 it gets hotter under the same load than before suspend.
> > So I can somewhat confirm your report.
> > 
> I can also confirm this behaviour with my acer tm4002lmi. it also has ja
> power consumption ~16W and after resuming it has round about 20W.

On a P35, a friend of mine determined that suspend to mem leads to a higher
power consumption if X was running. But only when using the ATI driver. When
using the vesa driver, the power consumption is increased to a higher rate 
all the time...

Other than the video driver, you can check whether PCI devices changed their
status (they shouldn't) by doing "lspci -vvv > lspci_before.txt" before
suspend, "lspci -vvv > lspci_after.txt" after suspend, and checking 
"diff -u lspci_before.txt lspci_after.txt".

Also, does the bus master activity rates typically seen (check 
/proc/acpi/processor/*/power every once in a while) differ
between pre-suspend and post-suspend?

	Dominik

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Resume -> higher power drain?

[Nils Faerber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Brodowski wrote:
> On a P35, a friend of mine determined that suspend to mem leads to a higher
> power consumption if X was running. But only when using the ATI driver. When
> using the vesa driver, the power consumption is increased to a higher rate 
> all the time...

You can decrease power with the x.org drivers and using the
	Option          "DynamicClocks" "on"
in the device sectio of xorg.conf. This will enable dynamic clock
scaling in the Radeon Fire GL and save quite some power.

> Other than the video driver, you can check whether PCI devices changed their
> status (they shouldn't) by doing "lspci -vvv > lspci_before.txt" before
> suspend, "lspci -vvv > lspci_after.txt" after suspend, and checking 
> "diff -u lspci_before.txt lspci_after.txt".

Just did that, no change so it seems PCI is safe.

> Also, does the bus master activity rates typically seen (check 
> /proc/acpi/processor/*/power every once in a while) differ
> between pre-suspend and post-suspend?

This again is interesting!
What does this bus master activity indicate?

Before suspend I see the CPU sporadically changing from C2 to C3 and
back and bus master activity to have values between 00000000 and some
higher values on activity, like 00200000 or even f0000000.

After suspend/resume this changed!
The CPU is now fixed at C2 and does not switch between C2 and C3.
Also the bus master activity is ffffffff in idle state and changes to
strange values on activity, like f7ffffff - quite different than before.

So, good spot!
And where can we go from here?
Is this already the possible cause?

> 	Dominik
CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfN57JXeIURG1qHgRAuKhAJoDzbAK6oN/2l+1/t6h5/mM3adGGQCfUFBy
1uLU7TtifkeGf2DVmKqE8K8=
=hprp
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Nils Faerber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nils Faerber wrote:
> Dominik Brodowski wrote:
>>>Also, does the bus master activity rates typically seen (check 
>>>/proc/acpi/processor/*/power every once in a while) differ
>>>between pre-suspend and post-suspend?
> This again is interesting!
> What does this bus master activity indicate?
> 
> Before suspend I see the CPU sporadically changing from C2 to C3 and
> back and bus master activity to have values between 00000000 and some
> higher values on activity, like 00200000 or even f0000000.
> 
> After suspend/resume this changed!
> The CPU is now fixed at C2 and does not switch between C2 and C3.
> Also the bus master activity is ffffffff in idle state and changes to
> strange values on activity, like f7ffffff - quite different than before.

OK, just fixed this ;)

The problem seemed to be related to suspend/resume scripts, so to say. I
did enable vbetool to save/restore VESA state and doing vbetool post.

Using s3_bios resume this is not necessary!

And after disabling vbetool usage at all the bus master activity is back
to normal again after resume!

So at least for my T42p I can recommend NOT to use vbetool at all for
suspend/resume but rather to use s3_bios!

> Is this already the possible cause?

Pityly it was not, at least not alone.

The CPU is now cooler again, where I got around 47°C before the fix it
is now back to normal 42°C and power consumption is roughly 1W down to
18W, but still 2W more than before.

So, still 2W to fix ;)
Any further ideas?

>>>	Dominik

Many thanks so far, really good pointers!

CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfOPvJXeIURG1qHgRArRiAJ9AsYcjijlShoDRXoIG9cr3f+YcKgCfYznK
NLz/DjwmAzScMZ0ifac0hC0=
=YIou
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Pavel Machek]

Hi!

> >>>Also, does the bus master activity rates typically seen (check 
> >>>/proc/acpi/processor/*/power every once in a while) differ
> >>>between pre-suspend and post-suspend?
> > This again is interesting!
> > What does this bus master activity indicate?
> > 
> > Before suspend I see the CPU sporadically changing from C2 to C3 and
> > back and bus master activity to have values between 00000000 and some
> > higher values on activity, like 00200000 or even f0000000.
> > 
> > After suspend/resume this changed!
> > The CPU is now fixed at C2 and does not switch between C2 and C3.
> > Also the bus master activity is ffffffff in idle state and changes to
> > strange values on activity, like f7ffffff - quite different than before.
> 
> OK, just fixed this ;)
> 
> The problem seemed to be related to suspend/resume scripts, so to say. I
> did enable vbetool to save/restore VESA state and doing vbetool post.
> 
> Using s3_bios resume this is not necessary!
> 
> And after disabling vbetool usage at all the bus master activity is back
> to normal again after resume!
> 
> So at least for my T42p I can recommend NOT to use vbetool at all for
> suspend/resume but rather to use s3_bios!

Can you suggest a patch to Documentation/power/video.txt?
								Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Nils Faerber]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pavel Machek wrote:
> Hi!
Hi!

>>The problem seemed to be related to suspend/resume scripts, so to say. I
>>did enable vbetool to save/restore VESA state and doing vbetool post.
>>
>>Using s3_bios resume this is not necessary!
>>
>>And after disabling vbetool usage at all the bus master activity is back
>>to normal again after resume!
>>
>>So at least for my T42p I can recommend NOT to use vbetool at all for
>>suspend/resume but rather to use s3_bios!
> 
> Can you suggest a patch to Documentation/power/video.txt?

I changed the file a little accordingly, a diff is attached.
I think it would be a good idea to start some compatibitlity
documentation, i.e. which device is known to work with which
options/tricks. I appended a "compatibility matrix" to the end of the file.

Tel me if you find this documentation useful or what can/should be
added/changed.

> 								Pavel
CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfUbdJXeIURG1qHgRAvmuAJ4/Q1a7HCdeNmpC3MtsGzQ3Z1Xl0QCdGlmz
T5SUaUZCiGtraA/Zc4zIcFY=
=aKR1
-----END PGP SIGNATURE-----

[-- Attachment #2: video.txt.diff --]
[-- Type: text/x-patch, Size: 2736 bytes --]

*** linux-2.6.11.8/Documentation/power/video.txt-o	Sun May  8 00:48:38 2005
--- linux-2.6.11.8/Documentation/power/video.txt	Sun May  8 00:45:58 2005
***************
*** 36,43 ****
  Now, if you pass acpi_sleep=something, and it does not work with your
  bios, you'll get hard crash during resume. Be carefull.
  
! You may have system where none of above works. At that point you
  either invent another ugly hack that works, or write proper driver for
  your video card (good luck getting docs :-(). Maybe suspending from X
  (proper X, knowing your hardware, not XF68_FBcon) might have better
  chance of working.
--- 36,84 ----
  Now, if you pass acpi_sleep=something, and it does not work with your
  bios, you'll get hard crash during resume. Be carefull.
  
! You may have a system where none of above works. At that point you
  either invent another ugly hack that works, or write proper driver for
  your video card (good luck getting docs :-(). Maybe suspending from X
  (proper X, knowing your hardware, not XF68_FBcon) might have better
  chance of working.
+ 
+ 
+ Other well known solutions to get your video back on resume using vbetool.
+ Vbetool can execude the real-mode video BIOS extension and use standard
+ video BIOS calls to alter the hardware state of your video hardware. There
+ are two ways to get video to resume:
+ 
+ * save your current video setting before going to suspend and restore it on
+   resume, like
+ 	vbetool save > /tmp/.vbe-settings
+ 	[go to sleep]
+ 	vbetool restore < /tmp/.vbe-settings
+   On many systems this will bring back your complete video hardware,
+   including backlight on notebook TFTs. This is known to work with many ATI
+   radeon systems and Intel Centrino.
+ 
+ * manually execute the video post method if you BIOS does not do it for you,
+   again vbetool can do this
+ 	vbetool post
+   This can on some systems already be enough to get your video back.
+ 
+ Warning: The above should only be tested in a safe environment like a single
+ user shell since it may be necessary to cold-reset your machine, your
+ machine might not resume correctly or simply crash hard.
+ 
+ 
+ Compatibility matrix for S3 resume:
+ 
+ Machine		s3_bios s3_mode vbe-save vbe-post recommended
+ -------------------------------------------------------------
+ HP Omnibook xe3s
+   Athlon           -       -       -        -        no special action required
+ IBM T42p           X       ?       X        X        s3_bios, vbe methods result in CPU bus master activity madness
+ Toshiba 4030cdt            X                         s3_mode
+ Toshiba Satellite
+   P10-554          X       X                         s3_bios,s3_mode
+ 
+ 
+ X = working
+ ? = unknown
+ - = not action required

Re: Resume -> higher power drain?

[Pavel Machek]

Hi!

> >>The problem seemed to be related to suspend/resume scripts, so to say. I
> >>did enable vbetool to save/restore VESA state and doing vbetool post.
> >>
> >>Using s3_bios resume this is not necessary!
> >>
> >>And after disabling vbetool usage at all the bus master activity is back
> >>to normal again after resume!
> >>
> >>So at least for my T42p I can recommend NOT to use vbetool at all for
> >>suspend/resume but rather to use s3_bios!
> > 
> > Can you suggest a patch to Documentation/power/video.txt?
> 
> I changed the file a little accordingly, a diff is attached.
> I think it would be a good idea to start some compatibitlity
> documentation, i.e. which device is known to work with which
> options/tricks. I appended a "compatibility matrix" to the end of the file.
> 
> Tel me if you find this documentation useful or what can/should be
> added/changed.

I do not think we should list multiple ways to make it work. Thats
just too complicated. Just one "best" method should be listed...

Oh and pleas make patches diff -u...
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Nils Faerber]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pavel Machek wrote:
> Hi!
Hi!

[...]
>>>>So at least for my T42p I can recommend NOT to use vbetool at all for
>>>>suspend/resume but rather to use s3_bios!
>>>Can you suggest a patch to Documentation/power/video.txt?
>>I changed the file a little accordingly, a diff is attached.
>>I think it would be a good idea to start some compatibitlity
>>documentation, i.e. which device is known to work with which
>>options/tricks. I appended a "compatibility matrix" to the end of the file.
>>
>>Tel me if you find this documentation useful or what can/should be
>>added/changed.
> 
> I do not think we should list multiple ways to make it work. Thats
> just too complicated. Just one "best" method should be listed...

OK, I removed the extra "X"'es from the table ;)

> Oh and pleas make patches diff -u...

Attached ;)

Do you have another idea what might cause the still extra ~2W power
drain I see after resume? Or any idea how to trace/find that?

> 								Pavel
Kind regards
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf0NLJXeIURG1qHgRAjAqAJsExKqTJEz5+gq9sEmEhda82MzOxACeJGFa
sRRiYWOBp90nUtUEOLF6/gw=
=FAlU
-----END PGP SIGNATURE-----

[-- Attachment #2: video.txt.diff --]
[-- Type: text/x-patch, Size: 2312 bytes --]

--- linux-2.6.11.8/Documentation/power/video.txt-o	2005-05-08 00:48:38.000000000 +0200
+++ linux-2.6.11.8/Documentation/power/video.txt	2005-05-09 13:00:19.000000000 +0200
@@ -36,8 +36,49 @@
 Now, if you pass acpi_sleep=something, and it does not work with your
 bios, you'll get hard crash during resume. Be carefull.
 
-You may have system where none of above works. At that point you
+You may have a system where none of above works. At that point you
 either invent another ugly hack that works, or write proper driver for
 your video card (good luck getting docs :-(). Maybe suspending from X
 (proper X, knowing your hardware, not XF68_FBcon) might have better
 chance of working.
+
+
+Other well known solutions to get your video back on resume using vbetool.
+Vbetool can execude the real-mode video BIOS extension and use standard
+video BIOS calls to alter the hardware state of your video hardware. There
+are two ways to get video to resume:
+
+* save your current video setting before going to suspend and restore it on
+  resume, like
+	vbetool save > /tmp/.vbe-settings
+	[go to sleep]
+	vbetool restore < /tmp/.vbe-settings
+  On many systems this will bring back your complete video hardware,
+  including backlight on notebook TFTs. This is known to work with many ATI
+  radeon systems and Intel Centrino.
+
+* manually execute the video post method if you BIOS does not do it for you,
+  again vbetool can do this
+	vbetool post
+  This can on some systems already be enough to get your video back.
+
+Warning: The above should only be tested in a safe environment like a single
+user shell since it may be necessary to cold-reset your machine, your
+machine might not resume correctly or simply crash hard.
+
+
+Compatibility matrix for S3 resume:
+
+Machine		s3_bios s3_mode vbe-save vbe-post recommended
+-------------------------------------------------------------
+HP Omnibook xe3s
+  Athlon           -       -       -        -        no special action required
+IBM T42p           X                                 s3_bios, vbe methods result in CPU bus master activity madness
+Toshiba 4030cdt            X                         s3_mode
+Toshiba Satellite
+  P10-554          X       X                         s3_bios,s3_mode
+
+
+X = working
+? = unknown
+- = not action required

Re: Resume -> higher power drain?

[Ow Mun Heng]

On Mon, 2005-05-09 at 13:02 +0200, Nils Faerber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pavel Machek wrote:
> > Hi!
> Hi!
> 
> [...]
> >>>>So at least for my T42p I can recommend NOT to use vbetool at all for
> >>>>suspend/resume but rather to use s3_bios!
> >>>Can you suggest a patch to Documentation/power/video.txt?
> >>I changed the file a little accordingly, a diff is attached.
> >>I think it would be a good idea to start some compatibitlity
> >>documentation, i.e. which device is known to work with which
> >>options/tricks. I appended a "compatibility matrix" to the end of the file.
> >>
> >>Tel me if you find this documentation useful or what can/should be
> >>added/changed.
> > 
> > I do not think we should list multiple ways to make it work. Thats
> > just too complicated. Just one "best" method should be listed...
> 
> OK, I removed the extra "X"'es from the table ;)

Put one on for D600 for S3_Bios..  didn't try S3_mode

but right now, I reverted to using suspend2 instead. 15 secs to
hibernate only.


-- 
Ow Mun Heng
Gentoo/Linux on DELL D600 1.4Ghz 
98% Microsoft(tm) Free!! 
Neuromancer 19:12:19 up 2:47, 5 users, load average: 0.41, 0.60, 0.71 




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Stefan Seyfried]

On Mon, May 09, 2005 at 07:12:20PM +0800, Ow Mun Heng wrote:

> > OK, I removed the extra "X"'es from the table ;)
> 
> Put one on for D600 for S3_Bios..  didn't try S3_mode

This is not a generally "known good" solution :-(
All my D600 and D800 reboot instead of resuming with _any_ acpi_sleep=
parameter. They only work with vga=normal and the X.org radeon driver
(D600) or the binary NVidia driver (D800) brings back the gfx card.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

Hi!

> [...]
> >>>>So at least for my T42p I can recommend NOT to use vbetool at all for
> >>>>suspend/resume but rather to use s3_bios!
> >>>Can you suggest a patch to Documentation/power/video.txt?
> >>I changed the file a little accordingly, a diff is attached.
> >>I think it would be a good idea to start some compatibitlity
> >>documentation, i.e. which device is known to work with which
> >>options/tricks. I appended a "compatibility matrix" to the end of the file.
> >>
> >>Tel me if you find this documentation useful or what can/should be
> >>added/changed.
> > 
> > I do not think we should list multiple ways to make it work. Thats
> > just too complicated. Just one "best" method should be listed...
> 
> OK, I removed the extra "X"'es from the table ;)

Hmm, sorry for not asking earlier. Do you think you could make it
relative to recent version of video.txt? [attached]

> > Oh and pleas make patches diff -u...
> 
> Attached ;)
> 
> Do you have another idea what might cause the still extra ~2W power
> drain I see after resume? Or any idea how to trace/find that?

You might want to try suspending with minimal drivers. If that does
not cure ~2W up, try searching for heat source after resume that was
not there before. 2W should be enough to be felt...


-- 
Boycott Kodak -- for their patent abuse against Java.

[-- Attachment #2: video.txt --]
[-- Type: text/plain, Size: 6815 bytes --]


		Video issues with S3 resume
		~~~~~~~~~~~~~~~~~~~~~~~~~~~
		  2003-2005, Pavel Machek

During S3 resume, hardware needs to be reinitialized. For most
devices, this is easy, and kernel driver knows how to do
it. Unfortunately there's one exception: video card. Those are usually
initialized by BIOS, and kernel does not have enough information to
boot video card. (Kernel usually does not even contain video card
driver -- vesafb and vgacon are widely used).

This is not problem for swsusp, because during swsusp resume, BIOS is
run normally so video card is normally initialized. S3 has absolutely
no chance of working with SMP/HT. Be sure it to turn it off before
testing (swsusp should work ok, OTOH).

There are a few types of systems where video works after S3 resume:

(1) systems where video state is preserved over S3.

(2) systems where it is possible to call the video BIOS during S3
  resume. Unfortunately, it is not correct to call the video BIOS at
  that point, but it happens to work on some machines. Use
  acpi_sleep=s3_bios.

(3) systems that initialize video card into vga text mode and where
  the BIOS works well enough to be able to set video mode. Use
  acpi_sleep=s3_mode on these.

(4) on some systems s3_bios kicks video into text mode, and
  acpi_sleep=s3_bios,s3_mode is needed.

(5) radeon systems, where X can soft-boot your video card. You'll need
  a new enough X, and a plain text console (no vesafb or radeonfb). See
  http://www.doesi.gmxhome.de/linux/tm800s3/s3.html for more information.
  Alternatively, you should use vbetool (6) instead.

(6) other radeon systems, where vbetool is enough to bring system back
  to life. It needs text console to be working. Do vbetool vbestate
  save > /tmp/delme; echo 3 > /proc/acpi/sleep; vbetool post; vbetool
  vbestate restore < /tmp/delme; setfont <whatever>, and your video
  should work.

(7) on some systems, it is possible to boot most of kernel, and then
  POSTing bios works. Ole Rohne has patch to do just that at
  http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.

Now, if you pass acpi_sleep=something, and it does not work with your
bios, you'll get a hard crash during resume. Be careful. Also it is
safest to do your experiments with plain old VGA console. The vesafb
and radeonfb (etc) drivers have a tendency to crash the machine during
resume.

You may have a system where none of above works. At that point you
either invent another ugly hack that works, or write proper driver for
your video card (good luck getting docs :-(). Maybe suspending from X
(proper X, knowing your hardware, not XF68_FBcon) might have better
chance of working.

Table of known working systems:

Model                           hack (or "how to do it")
------------------------------------------------------------------------------
Acer Aspire 1406LC		ole's late BIOS init (7), turn off DRI
Acer TM 242FX			vbetool (6)
Acer TM C300                    vga=normal (only suspend on console, not in X), vbetool (6)
Acer TM 4052LCi		        s3_bios (2)
Acer TM 636Lci			s3_bios vga=normal (2)
Acer TM 650 (Radeon M7)		vga=normal plus boot-radeon (5) gets text console back
Acer TM 660			??? (*)
Acer TM 800			vga=normal, X patches, see webpage (5) or vbetool (6)
Acer TM 803			vga=normal, X patches, see webpage (5) or vbetool (6)
Acer TM 803LCi			vga=normal, vbetool (6)
Arima W730a			vbetool needed (6)
Asus L2400D                     s3_mode (3)(***) (S1 also works OK)
Asus L3350M (SiS 740)           (6)
Asus L3800C (Radeon M7)		s3_bios (2) (S1 also works OK)
Asus M6887Ne			vga=normal, s3_bios (2), use radeon driver instead of fglrx in x.org
Athlon64 desktop prototype	s3_bios (2)
Compal CL-50			??? (*)
Compaq Armada E500 - P3-700     none (1) (S1 also works OK)
Compaq Evo N620c		vga=normal, s3_bios (2)
Dell 600m, ATI R250 Lf		none (1), but needs xorg-x11-6.8.1.902-1
Dell D600, ATI RV250            vga=normal and X, or try vbestate (6)
Dell Inspiron 4000		??? (*)
Dell Inspiron 500m		??? (*)
Dell Inspiron 600m		??? (*)
Dell Inspiron 8200		??? (*)
Dell Inspiron 8500		??? (*)
Dell Inspiron 8600		??? (*)
eMachines athlon64 machines	vbetool needed (6) (someone please get me model #s)
HP NC6000			s3_bios, may not use radeonfb (2); or vbetool (6)
HP NX7000			??? (*)
HP Pavilion ZD7000		vbetool post needed, need open-source nv driver for X
HP Omnibook XE3	athlon version	none (1)
HP Omnibook XE3GC		none (1), video is S3 Savage/IX-MV
IBM TP T20, model 2647-44G	none (1), video is S3 Inc. 86C270-294 Savage/IX-MV, vesafb gets "interesting" but X work.
IBM TP A31 / Type 2652-M5G      s3_mode (3) [works ok with BIOS 1.04 2002-08-23, but not at all with BIOS 1.11 2004-11-05 :-(]
IBM TP R32 / Type 2658-MMG      none (1)
IBM TP R40 2722B3G		??? (*)
IBM TP R50p / Type 1832-22U     s3_bios (2)
IBM TP R51			none (1)
IBM TP T30	236681A		??? (*)
IBM TP T40 / Type 2373-MU4      none (1)
IBM TP T40p			none (1)
IBM TP R40p			s3_bios (2)
IBM TP T41p			s3_bios (2), switch to X after resume
IBM TP T42			s3_bios (2)
IBM ThinkPad T42p (2373-GTG)	s3_bios (2)
IBM TP X20			??? (*)
IBM TP X30			s3_bios (2)
IBM TP X31 / Type 2672-XXH      none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight.
IBM Thinkpad X40 Type 2371-7JG  s3_bios,s3_mode (4)
Medion MD4220			??? (*)
Samsung P35			vbetool needed (6)
Sharp PC-AR10 (ATI rage)	none (1)
Sony Vaio PCG-F403		??? (*)
Sony Vaio PCG-N505SN		??? (*)
Sony Vaio vgn-s260		X or boot-radeon can init it (5)
Toshiba Libretto L5		none (1)
Toshiba Satellite 4030CDT	s3_mode (3)
Toshiba Satellite 4080XCDT      s3_mode (3)
Toshiba Satellite 4090XCDT      ??? (*)
Toshiba Satellite P10-554       s3_bios,s3_mode (4)(****)
Uniwill 244IIO			??? (*)


(*) from http://www.ubuntulinux.org/wiki/HoaryPMResults, not sure
    which options to use. If you know, please tell me.

(***) To be tested with a newer kernel.

(****) Not with SMP kernel, UP only.

VBEtool details
~~~~~~~~~~~~~~~
(with thanks to Carl-Daniel Hailfinger)

First, boot into X and run the following script ONCE:
#!/bin/bash
statedir=/root/s3/state
mkdir -p $statedir
chvt 2
sleep 1
vbetool vbestate save >$statedir/vbe


To suspend and resume properly, call the following script as root:
#!/bin/bash
statedir=/root/s3/state
curcons=`fgconsole`
fuser /dev/tty$curcons 2>/dev/null|xargs ps -o comm= -p|grep -q X && chvt 2
cat /dev/vcsa >$statedir/vcsa
sync
echo 3 >/proc/acpi/sleep
sync
vbetool post
vbetool vbestate restore <$statedir/vbe
cat $statedir/vcsa >/dev/vcsa
rckbd restart
chvt $[curcons%6+1]
chvt $curcons


Unless you change your graphics card or other hardware configuration,
the state once saved will be OK for every resume afterwards.
NOTE: The "rckbd restart" command may be different for your
distribution. Simply replace it with the command you would use to
set the fonts on screen.

Re: Resume -> higher power drain?

[Stefan Seyfried]

On Sat, May 07, 2005 at 10:02:25PM +0200, Pavel Machek wrote:

> > So at least for my T42p I can recommend NOT to use vbetool at all for
> > suspend/resume but rather to use s3_bios!
> 
> Can you suggest a patch to Documentation/power/video.txt?

according to some X guys, vbetool vbestate save/restore is "problematic"
at least and should only be used as a measure of last resort, if everything
else fails.

That said, a recent X.org radeon driver should post the card, bring the light
back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
chipsets
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
> That said, a recent X.org radeon driver should post the card, bring the light
> back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
> chipsets

How recent? Does this driver also turn off the backlight during S3?

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: Resume -> higher power drain?

[Matthew Garrett]

On Mon, 2005-05-09 at 14:53 +0200, Henrik Brix Andersen wrote:
> On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
> > That said, a recent X.org radeon driver should post the card, bring the light
> > back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
> > chipsets
> 
> How recent? Does this driver also turn off the backlight during S3?

Unlikely. At the moment, X doesn't know that the system is suspending.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Nils Faerber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Garrett wrote:
> On Mon, 2005-05-09 at 14:53 +0200, Henrik Brix Andersen wrote:
>>On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
>>>That said, a recent X.org radeon driver should post the card, bring the light
>>>back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
>>>chipsets
>>How recent? Does this driver also turn off the backlight during S3?
> Unlikely. At the moment, X doesn't know that the system is suspending.

And additionally switching the light off is what seems to work most
reliably on most platforms - just the way back seems to be more critical ;)

CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf2u0JXeIURG1qHgRAh8rAKDP7rABItff09qN+3aelZvfGaKkjACgw127
kOpzujOrjDBwN1Ct5T64PFQ=
=gzy+
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Stefan Seyfried]

On Mon, May 09, 2005 at 02:53:14PM +0200, Henrik Brix Andersen wrote:
> On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
> > That said, a recent X.org radeon driver should post the card, bring the light
> > back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
> > chipsets
> 
> How recent? 

seife@strolchi:~> X -version
X Window System Version 6.8.2
Release Date: 9 February 2005

> Does this driver also turn off the backlight during S3?

Well, i have never had problems with the light not turning off during S3
except for one very crappy SHARP machine, but that one turned it off on
lid close, so that was no problem. So usually the problem is getting the
light back _on_ after resume :-)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Matthew Garrett]

On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
> On Sat, May 07, 2005 at 10:02:25PM +0200, Pavel Machek wrote:
> 
> > > So at least for my T42p I can recommend NOT to use vbetool at all for
> > > suspend/resume but rather to use s3_bios!
> > 
> > Can you suggest a patch to Documentation/power/video.txt?
> 
> according to some X guys, vbetool vbestate save/restore is "problematic"
> at least and should only be used as a measure of last resort, if everything
> else fails.

The main advantage of saving/restoring the VBE state is that the code to
do so is likely to actually be there, which is something that you can't
say about POSTing. As far as I can tell, there shouldn't be any issue in
making vbestate calls from text mode, especially in situations where the
alternative is to have no graphics functionality at all. It would be
interesting to look at video card state to see what the difference is
afterwards...

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Stefan Seyfried]

On Mon, May 09, 2005 at 02:38:06PM +0100, Matthew Garrett wrote:
> On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
> 
> > according to some X guys, vbetool vbestate save/restore is "problematic"
> > at least and should only be used as a measure of last resort, if everything
> > else fails.

Again, to be clear: this is not my wisdom but from people who know the radeon
chips prettty good (Matthias Hopf, among others)

> The main advantage of saving/restoring the VBE state is that the code to
> do so is likely to actually be there, which is something that you can't
> say about POSTing. As far as I can tell, there shouldn't be any issue in

The radeon X driver apparently knows enough about the chips to re-post them.
Excerpt from my X log:
(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
(II) RADEON(0): Primary V_BIOS segment is: 0xc000

> making vbestate calls from text mode, especially in situations where the
> alternative is to have no graphics functionality at all. It would be

Thats what i meant with "only be used as a measure of last resort" :-)

> interesting to look at video card state to see what the difference is
> afterwards...

Probably. Note that i have no knowledge about graphics cards at all, i just
tell what i have been told ;-)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Matthew Garrett]

On Mon, 2005-05-09 at 20:28 +0200, Stefan Seyfried wrote:
> On Mon, May 09, 2005 at 02:38:06PM +0100, Matthew Garrett wrote:

> > The main advantage of saving/restoring the VBE state is that the code to
> > do so is likely to actually be there, which is something that you can't
> > say about POSTing. As far as I can tell, there shouldn't be any issue in
> 
> The radeon X driver apparently knows enough about the chips to re-post them.
> Excerpt from my X log:
> (WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
> (II) RADEON(0): Primary V_BIOS segment is: 0xc000

Right, but that's only possible if the video BIOS code is still there.
It often isn't, at which point your X server is executing random code.
That's generally a bad thing.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Re: Resume -> higher power drain?

[Carl-Daniel Hailfinger]

Stefan Seyfried schrieb:
> On Mon, May 09, 2005 at 02:38:06PM +0100, Matthew Garrett wrote:
> 
>>On Mon, 2005-05-09 at 11:07 +0200, Stefan Seyfried wrote:
>>
>>
>>>according to some X guys, vbetool vbestate save/restore is "problematic"
>>>at least and should only be used as a measure of last resort, if everything
>>>else fails.
> 
> 
> Again, to be clear: this is not my wisdom but from people who know the radeon
> chips prettty good (Matthias Hopf, among others)
> 
> 
>>The main advantage of saving/restoring the VBE state is that the code to
>>do so is likely to actually be there, which is something that you can't
>>say about POSTing. As far as I can tell, there shouldn't be any issue in
> 
> 
> The radeon X driver apparently knows enough about the chips to re-post them.
> Excerpt from my X log:
> (WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
> (II) RADEON(0): Primary V_BIOS segment is: 0xc000

Can you please ask the gurus: What is the difference between POSTing with
the X driver and POSTing with vbetool, if both versions use int10? And can
I have the "better int10" of the X driver as an isolated piece of code so
that resume will eventually work even if X is not running?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Re: Resume -> higher power drain?

[Carl-Daniel Hailfinger]

Stefan Seyfried schrieb:
> On Sat, May 07, 2005 at 10:02:25PM +0200, Pavel Machek wrote:
> 
> 
>>>So at least for my T42p I can recommend NOT to use vbetool at all for
>>>suspend/resume but rather to use s3_bios!
>>
>>Can you suggest a patch to Documentation/power/video.txt?
> 
> 
> according to some X guys, vbetool vbestate save/restore is "problematic"
> at least and should only be used as a measure of last resort, if everything
> else fails.
> 
> That said, a recent X.org radeon driver should post the card, bring the light
> back on (it does on my Dell D600) and make vbetool unnecessary on ATI radeon
> chipsets

A recent X.org radeon driver will switch on the backlight and crash
afterwards on my Samsung P35, exactly the thing "vbetool post" does.
However, POSTing is not enough for my card, I have to restore the
vesa state to actually see something on screen.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Pavel Machek]

Hi!

> I just observed a strange phenomenon on my new T42p (latest BIOS).
> I can successfully suspend and resume to and from S3 and S4!
> Kernel ist vanilla 2.6.11.8 using ACPI support scripts from the Ubuntu
> acpi-support package (removes critical modules, does vbe save and
> restore, etc...)
> So far very fine and indeed good work.
> 
> Before suspend I usually see a power consumption of about 16W including
> WLAN, which is nicely low.
> But strangely after resume from either S3 or S4 I have see a power
> consumption of 19W+. This means ~3W more or in other words, roughly 20%
> less runtime.
> This is pretty annoying - not a real show-stoppper but it would be nicer
> without ;)
> 
> I have no idea how to diagnose this. My first guess is that some devices
> are not resumed correctly but I have no real idea how for example gather
> device states before and after suspend, or other means to diagnose this.
> 
> So, if anyone has an idea how I can diagnose this and help this issue to
> be solved, let me know. Or is there already a solution floating around?

Is cpufreq working correctly after resume?

									Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Resume -> higher power drain?

[Nils Faerber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pavel Machek wrote:
> Hi!

Hi!

>>Before suspend I usually see a power consumption of about 16W including
>>WLAN, which is nicely low.
>>But strangely after resume from either S3 or S4 I have see a power
>>consumption of 19W+. This means ~3W more or in other words, roughly 20%
>>less runtime.
>>This is pretty annoying - not a real show-stoppper but it would be nicer
>>without ;)
>>
>>I have no idea how to diagnose this. My first guess is that some devices
>>are not resumed correctly but I have no real idea how for example gather
>>device states before and after suspend, or other means to diagnose this.
>>
>>So, if anyone has an idea how I can diagnose this and help this issue to
>>be solved, let me know. Or is there already a solution floating around?
> 
> Is cpufreq working correctly after resume?

As to all I can observe, yes.
I have powernowd running and it nicely changes frequency up and down and
changes show up in /proc/cpuinfo accordingly (as well as in gkrellm's
cpu frequency monitor).
So I guess, yes, it works.

Any other ideas what to check for?

> 									Pavel
CU
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfUfYJXeIURG1qHgRAoPSAKCBFTkCPSTUyPBCgsV33iwYZSaprQCfWVp/
6mgly24OKJyMbgcW+twdq54=
=BQFP
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20