[2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

Hello, 

I've noticed something strange with issuing 'standby' to the system:

when echoing "standby" to /sys/power/state, nothing happens, not even a log or 
system activity to attempt standby mode.

However, trying echo "1" to /proc/acpi/sleep the system attempts to (standby) 
and aborts:

[4295945.236000] PM: Preparing system for suspend
[4295946.270000] Stopping tasks: 
=============================================================================|
[4295946.370000] Restarting tasks... done

We get no reason as to why it quickly aborts. 

[4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[4294676.827000] ACPI: (supports S0 S3 S4 S5)

What is '1' in /proc/acpi/sleep?  standby mode is not the same as suspend to 
ram? when I put a normal desktop in standby mode its still 'on' but the hard 
disk is put to sleep and the system runs in a lower power mode. 

Shawn.

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Pavel Machek]

Hi!

> I've noticed something strange with issuing 'standby' to the system:
> 
> when echoing "standby" to /sys/power/state, nothing happens, not even a log or 
> system activity to attempt standby mode.
> 
> However, trying echo "1" to /proc/acpi/sleep the system attempts to (standby) 
> and aborts:
> 
> [4295945.236000] PM: Preparing system for suspend
> [4295946.270000] Stopping tasks: 
> =============================================================================|
> [4295946.370000] Restarting tasks... done
> 
> We get no reason as to why it quickly aborts. 

> [4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> [4294676.827000] ACPI: (supports S0 S3 S4 S5)


...aha, but your system does not support S1 aka standby.
 
> What is '1' in /proc/acpi/sleep?  standby mode is not the same as suspend to 
> ram? when I put a normal desktop in standby mode its still 'on' but the hard 
> disk is put to sleep and the system runs in a lower power mode. 

stanby != suspend to ram.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

I'm working o

--- Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
> 
> > I've noticed something strange with issuing
> 'standby' to the system:
> > 
> > when echoing "standby" to /sys/power/state,
> nothing happens, not even a log or 
> > system activity to attempt standby mode.
> > 
> > However, trying echo "1" to /proc/acpi/sleep the
> system attempts to (standby) 
> > and aborts:
> > 
> > [4295945.236000] PM: Preparing system for suspend
> > [4295946.270000] Stopping tasks: 
> >
>
=============================================================================|
> > [4295946.370000] Restarting tasks... done
> > 
> > We get no reason as to why it quickly aborts. 
> 
> > [4294672.065000] ACPI: CPU0 (power states: C1[C1]
> C2[C2] C3[C3])
> > [4294676.827000] ACPI: (supports S0 S3 S4 S5)
> 
> 
> ...aha, but your system does not support S1 aka
> standby.
>  

Right, so nothing should happen if I try to do it, but
something does only in /proc/acpi/sleep does the
system attempt S1 which is not supported.

Do you know if /proc/acpi/sleep will be deprecated in
favour of /sys/power/state? If so, this thread will be
moot ;)

> > What is '1' in /proc/acpi/sleep?  standby mode is
> not the same as suspend to 
> > ram? when I put a normal desktop in standby mode
> its still 'on' but the hard 
> > disk is put to sleep and the system runs in a
> lower power mode. 
> 
> stanby != suspend to ram.

Correct, I wanted to be sure.

> 
> 				Pavel
> -- 
> 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51
> time=448769.1 ms         
> 
> 

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Pavel Machek]

Hi!

> I'm working o

???

> > > [4294672.065000] ACPI: CPU0 (power states: C1[C1]
> > C2[C2] C3[C3])
> > > [4294676.827000] ACPI: (supports S0 S3 S4 S5)
> > 
> > 
> > ...aha, but your system does not support S1 aka
> > standby.
> >  
> 
> Right, so nothing should happen if I try to do it, but
> something does only in /proc/acpi/sleep does the
> system attempt S1 which is not supported.

Feel free to fix it :-).

> Do you know if /proc/acpi/sleep will be deprecated in
> favour of /sys/power/state? If so, this thread will be
> moot ;)

No idea, deprecating it would be ok with me. 

							Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

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

So nobody minds if I make this into a CONFIG option marked as Deprecated? :)

Shawn.

>
> > Do you know if /proc/acpi/sleep will be deprecated in
> > favour of /sys/power/state? If so, this thread will be
> > moot ;)
>
> No idea, deprecating it would be ok with me.
>
>        Pavel

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

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Pavel Machek]

Hi!

> So nobody minds if I make this into a CONFIG option marked as Deprecated? :)

Actually it should probably go through

Documentation/feature-removal-schedule.txt

...and give it *long* timeout, since it is API change.
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

Yeah, I can do that, I don't need angry programmers
chasing after me :-)

Shawn.

--- Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
> 
> > So nobody minds if I make this into a CONFIG
> option marked as Deprecated? :)
> 
> Actually it should probably go through
> 
> Documentation/feature-removal-schedule.txt
> 
> ...and give it *long* timeout, since it is API
> change.
> 									Pavel
> -- 
> People were complaining that M$ turns users into
> beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb
> yvxr vg gung jnl!
>