RE: Re: Resume -> higher power drain?

RE: Re: Resume -> higher power drain?

[balister]

x.org from FC3 handles video suspending fine on my 600m.

Philip

>===== Original Message From Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> =====
>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
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
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 09:57 -0400, balister wrote:
> x.org from FC3 handles video suspending fine on my 600m.

No, x.org from FC3 does nothing whatsoever when you suspend your 600m,
because X doesn't know that the system is suspending. That's fine,
though, because (for the most part) we don't /want/ the X server to fuck
about with the video registers since on resume we're going to fuck about
with them ourselves.
-- 
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

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?

[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