Re: Re: [Swsusp-devel] ACPI A/C adaptor status not updated upon resume

[Ka-shu Wong <kswong-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>]

On Fri, Jul 18, 2003 at 04:53:22PM -0700, Grover, Andrew wrote:
> > 000031bd:     Method _PSR (\_SB_.ADP1._PSR)
> > 000031c3:       ArgCount 0; NotSerialized
> > 000031c4:       Return
> > 000031c5:         \_SB_.MEM_.ACST (000002da)
...
> See, now your system is different from Eric's, which looks like this:
...
>             Method (_PSR, 0, NotSerialized)
>             {
>                 Return (\_SB.MEM.ACST)
>             }

That's strange, it looks the same to me.

> Basically, I am at a loss as to why Eric's machine would report the
> wrong thing. Whoever is setting that bit in memory isn't doing it
> properly, for some reason. (There could be a lot of reasons. Eric, you
> might try sticking a printk in the memory read function in
> drivers/acpi/osl.c and seeing that we are doing a read from 0x000EE8FF
> and what the value is.)

I believe what's happening is that software suspend is somehow saving 
the ACPI state on suspend, and after resume the state from before 
suspend (which is no longer valid) is restored.

If the ACPI state is stored in kernel memory, then this makes sense.

So, my question (to the swsusp people) is whether it is possible to stop
swsusp from restoring the old (invalid) ACPI state; and
(to the ACPI people) is whether it is possible to reset the ACPI
subsystem in some way.

- KS


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0