Ask devices to powerdown before S3 sleep

Ask devices to powerdown before S3 sleep

[Pavel Machek]

Hi!

SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
SUSPEND_DISABLE should be so simple that errors just should not be
there, and besides we would not know how to safely enable devices from
such weird state, anyway]. Please apply,

								Pavel

--- clean/drivers/acpi/sleep.c	2003-01-05 22:58:25.000000000 +0100
+++ linux-swsusp/drivers/acpi/sleep.c	2003-01-19 21:27:00.000000000 +0100
@@ -143,6 +143,10 @@
 			return error;
 		}
 
+		error = device_suspend(state, SUSPEND_DISABLE);
+		if (error)
+			panic("Sorry, devices really should know how to disable\n");
+
 		/* flush caches */
 		ACPI_FLUSH_CPU_CACHE();

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Ask devices to powerdown before S3 sleep

[Andre Hedrick]

Hi! Pavel,

Could you do me just one tiny favor?
Please consider attempting an error recovery level path, maybe ...

Every patch I have glanced at has 'panic("blah blah");'

If you do not have enough hardware to generate an accurate path for
recovery, then please do not force the kernel into panic.  Would you
consider failing the request making it jump back to S1 ?  This at least
allows it crash like a power failure.

Cheers,

Andre Hedrick
LAD Storage Consulting Group


On Sun, 19 Jan 2003, Pavel Machek wrote:

> Hi!
> 
> SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
> SUSPEND_DISABLE should be so simple that errors just should not be
> there, and besides we would not know how to safely enable devices from
> such weird state, anyway]. Please apply,
> 
> 								Pavel
> 
> --- clean/drivers/acpi/sleep.c	2003-01-05 22:58:25.000000000 +0100
> +++ linux-swsusp/drivers/acpi/sleep.c	2003-01-19 21:27:00.000000000 +0100
> @@ -143,6 +143,10 @@
>  			return error;
>  		}
>  
> +		error = device_suspend(state, SUSPEND_DISABLE);
> +		if (error)
> +			panic("Sorry, devices really should know how to disable\n");
> +
>  		/* flush caches */
>  		ACPI_FLUSH_CPU_CACHE();
> 
> -- 
> Worst form of spam? Adding advertisment signatures ala sourceforge.net.
> What goes next? Inserting advertisment *into* email?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Ask devices to powerdown before S3 sleep

[Zwane Mwaikambo]

On Sun, 19 Jan 2003, Pavel Machek wrote:

> SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
> SUSPEND_DISABLE should be so simple that errors just should not be
> there, and besides we would not know how to safely enable devices from
> such weird state, anyway]. Please apply,

panic() is a bit on the extreme side no? I know diddly about ACPI and 
the current code, but can't you check for _PS3 methods or _S3D mappings 
for your devices before hand to be certain that the system can even go 
down to S3 somewhat reliably?

	Zwane
-- 
function.linuxpower.ca

Re: Ask devices to powerdown before S3 sleep

[Pavel Machek]

Hi!

> > SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
> > SUSPEND_DISABLE should be so simple that errors just should not be
> > there, and besides we would not know how to safely enable devices from
> > such weird state, anyway]. Please apply,
> 
> panic() is a bit on the extreme side no? I know diddly about ACPI and 
> the current code, but can't you check for _PS3 methods or _S3D mappings 
> for your devices before hand to be certain that the system can even go 
> down to S3 somewhat reliably?

At this point, you already DISABLED half of devices, and you don't
even know *which* ones. You can't just send them ENABLE and hope it
works.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Ask devices to powerdown before S3 sleep

[Pavel Machek]

Hi!

> Could you do me just one tiny favor?
> Please consider attempting an error recovery level path, maybe ...
> 
> Every patch I have glanced at has 'panic("blah blah");'
> 
> If you do not have enough hardware to generate an accurate path for
> recovery, then please do not force the kernel into panic.  Would you
> consider failing the request making it jump back to S1 ?  This at least
> allows it crash like a power failure.

If I make it go S1, auto-reboot will not apply etc, and machine will
crash during ENABLE, anyway...
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Ask devices to powerdown before S3 sleep

[Zwane Mwaikambo]

On Tue, 21 Jan 2003, Pavel Machek wrote:

> Hi!
> 
> > > SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
> > > SUSPEND_DISABLE should be so simple that errors just should not be
> > > there, and besides we would not know how to safely enable devices from
> > > such weird state, anyway]. Please apply,
> > 
> > panic() is a bit on the extreme side no? I know diddly about ACPI and 
> > the current code, but can't you check for _PS3 methods or _S3D mappings 
> > for your devices before hand to be certain that the system can even go 
> > down to S3 somewhat reliably?
> 
> At this point, you already DISABLED half of devices, and you don't
> even know *which* ones. You can't just send them ENABLE and hope it
> works.

I meant checking before you even attempt starting the process of doing S3.

	Zwane
-- 
function.linuxpower.ca

Re: Ask devices to powerdown before S3 sleep

[Pavel Machek]

Hi!

> > > > SUSPEND_RESUME phase is needed for turning off IO-APIC. [I believe
> > > > SUSPEND_DISABLE should be so simple that errors just should not be
> > > > there, and besides we would not know how to safely enable devices from
> > > > such weird state, anyway]. Please apply,
> > > 
> > > panic() is a bit on the extreme side no? I know diddly about ACPI and 
> > > the current code, but can't you check for _PS3 methods or _S3D mappings 
> > > for your devices before hand to be certain that the system can even go 
> > > down to S3 somewhat reliably?
> > 
> > At this point, you already DISABLED half of devices, and you don't
> > even know *which* ones. You can't just send them ENABLE and hope it
> > works.
> 
> I meant checking before you even attempt starting the process of doing S3.

All devices should support that -- BIOS should not advertise S3 if it
can not do that, and kernel should be fixed to work.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Ask devices to powerdown before S3 sleep

[Andre Hedrick]

Pavel,

I failed to make the point clear.
One thing I learned was never trust the BIOS, even if you wrote it.

Now if you are missing ACPI hooks to beat the BIOS silly for whatever
reason you want, I will load two barrels towards Andy for not finishing
the task or not explaining how to throttle them.

I do not care if the BIOS want to do monkey flips.
If there is an event any piece of hardware can not handle, ie where you
have inserted tests that default to panic, it had better allow you to
throttle to full enable.

If it does not, the solution is to make a blackball list of hardware
which fails to conform to acpi rules.  Fair warning you had better have a
means to prove it because, public lists make companies nervous.

So, that I am clear ... would you consider changing the default method of
operations for errors.

How a BUG() and a really long long timer until the battery dies, a panic
gives little or no information, but this is my opinion.

Cheers,


Andre Hedrick
LAD Storage Consulting Group

On Tue, 21 Jan 2003, Pavel Machek wrote:

> Hi!
> 
> > Could you do me just one tiny favor?
> > Please consider attempting an error recovery level path, maybe ...
> > 
> > Every patch I have glanced at has 'panic("blah blah");'
> > 
> > If you do not have enough hardware to generate an accurate path for
> > recovery, then please do not force the kernel into panic.  Would you
> > consider failing the request making it jump back to S1 ?  This at least
> > allows it crash like a power failure.
> 
> If I make it go S1, auto-reboot will not apply etc, and machine will
> crash during ENABLE, anyway...