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

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

[Grover, Andrew]

> From: Ka-shu Wong [mailto:kswong-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org] 
> Has there been any progress on this issue?
> 
> I'm running kernel 2.4.21 with acpi-20030619 and swsusp-1.0.2 on my
> toshiba portege 2000, and I'm getting the same problem.
> 
> Disassembling the _PSR method gives:
> 
> 000031bd:     Method _PSR (\_SB_.ADP1._PSR)
> 000031c3:       ArgCount 0; NotSerialized
> 000031c4:       Return
> 000031c5:         \_SB_.MEM_.ACST (000002da)
> 
> It seems that it is storing its state somewhere and changing it based
> on events.  Software suspend is probably saving this state 
> and restoring
> it upon resume.

See, now your system is different from Eric's, which looks like this:
        Device (MEM) {
            OperationRegion (SRAM, SystemMemory, 0x000EE800, 0x1800)
            Field (SRAM, AnyAcc, NoLock, Preserve)
            {
 		...
                Offset (0xFF), 
                ACST,   1, 
		...
		}

            Method (_PSR, 0, NotSerialized)
            {
                Return (\_SB.MEM.ACST)
            }

So, all his _PSR does is check a bit in system memory, whereas yours
calls another control method, so I don't know what your machine does
from there. Can you go look?

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.)

Regards -- Andy

PS if you're curious the EE8FF is because the SRAM operation region is
defined as a memory range starting at 0xEE800, and ACST is a field
offset 0xFF bytes from that.
PPS if you look at the E820 map on bootup, this should be in reserved
space.
PPPS ok that's it everyone have a great weekend! ;-)


-------------------------------------------------------
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

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

[Ka-shu Wong]

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

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

[Nigel Cunningham]

Hi.

Yes, swsusp will be storing the ACPI state (along with all the rest of
memory). Swsusp has no way to tell whether the state is invalid or not,
or to exclude arbitrary parts of the memory from the image (particularly
since we're probably not talking about a whole page here). The easiest
way to overcome this problem at the moment is to make sure the state is
the same when you resume as it is when you suspend. Failing that, a DSDT
override that does the right thing. Does unplugging and plugging in the
power post resume get the BIOS to set things right?

Regards,

Nigel

On Sat, 2003-07-19 at 16:13, Ka-shu Wong wrote:
> 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
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

You see, at just the right time, when we were still powerless,
Christ died for the ungodly.
	-- Romans 5:6, NIV.



-------------------------------------------------------
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

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

[Eric Altendorf]

On Friday 18 July 2003 21:54, Nigel Cunningham wrote:
> Hi.
>
> Yes, swsusp will be storing the ACPI state (along with all the rest
> of memory). Swsusp has no way to tell whether the state is invalid
> or not, or to exclude arbitrary parts of the memory from the image
> (particularly since we're probably not talking about a whole page
> here). The easiest way to overcome this problem at the moment is to
> make sure the state is the same when you resume as it is when you
> suspend. Failing that, a DSDT override that does the right thing.
> Does unplugging and plugging in the power post resume get the BIOS
> to set things right?

Yes, but only if the post is live, which generally isn't the case when 
this problem pops up. :-)

Eric


-------------------------------------------------------
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

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

[Ka-shu Wong]

I wish it was that easy..

Unfortunately rmmod/insmoding the AC module does not work because the
state is not stored in the AC module.

- KS


On Sat, Jul 19, 2003 at 03:20:23AM +0200, Gabor FLEISCHER wrote:
> On Sat, Jul 19, 2003 at 09:38:47AM +1000, Ka-shu Wong <kswong-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org> wrote:
> > There are two possible solutions that I can see:  Either make software
> > suspend not restore the ACPI state, or reset the ACPI subsystem somehow
> > after restore.
> > 
> > Are either of these solutions possible?
> 
> Yes, the second: if you compile AC as module, you can rmmod it before
> suspend, and insmod it after suspend.
> 
> Gavriel
> 


-------------------------------------------------------
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

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

[Gabor FLEISCHER]

On Sat, Jul 19, 2003 at 09:38:47AM +1000, Ka-shu Wong <kswong-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org> wrote:
> There are two possible solutions that I can see:  Either make software
> suspend not restore the ACPI state, or reset the ACPI subsystem somehow
> after restore.
> 
> Are either of these solutions possible?

Yes, the second: if you compile AC as module, you can rmmod it before
suspend, and insmod it after suspend.

Gavriel


-------------------------------------------------------
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

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

[Grover, Andrew]

> From: Grover, Andrew 

> 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.)
> 
> Regards -- Andy
> 
> PS if you're curious the EE8FF is because the SRAM operation region is
> defined as a memory range starting at 0xEE800, and ACST is a field
> offset 0xFF bytes from that.

Or actually the read would be at 0xEE900. Sorry.

Regards -- Andy


-------------------------------------------------------
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

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

[Ka-shu Wong]

Has there been any progress on this issue?

I'm running kernel 2.4.21 with acpi-20030619 and swsusp-1.0.2 on my
toshiba portege 2000, and I'm getting the same problem.

Disassembling the _PSR method gives:

000031bd:     Method _PSR (\_SB_.ADP1._PSR)
000031c3:       ArgCount 0; NotSerialized
000031c4:       Return
000031c5:         \_SB_.MEM_.ACST (000002da)

It seems that it is storing its state somewhere and changing it based
on events.  Software suspend is probably saving this state and restoring
it upon resume.

There are two possible solutions that I can see:  Either make software
suspend not restore the ACPI state, or reset the ACPI subsystem somehow
after restore.

Are either of these solutions possible?

- KS

PS I'm not on the ACPI list so please CC.


On Thu, Jul 17, 2003 at 01:49:51PM -0700, Grover, Andrew wrote:
> Well we actually are calling the _PSR control method to implement the
> "state" proc entry. Of course, that's just calling a control method so
> who knows what the control method does -- I'd have to see what _PSR
> looks like...can you get your dsdt from /proc/acpi/dsdt, disassemble
> with iasl -d and post what _PSR is?
> 
> Thanks -- Regards -- Andy
> 
> > -----Original Message-----
> > From: Nigel Cunningham [mailto:ncunningham-oKK1aGe2n869koe0gwxAeg@public.gmane.org] 
> > Sent: Thursday, July 17, 2003 1:20 PM
> > To: EricAltendorf-gZ4DH+Stb0k@public.gmane.org
> > Cc: swsusp-devel; ACPI List
> > Subject: [ACPI] Re: [Swsusp-devel] ACPI A/C adaptor status 
> > not updated upon resume
> > 
> > 
> > That's ACPI, not swsusp - it must be toggling the state based 
> > on events,
> > not actually detecting it.
> > 
> > Regards,
> > 
> > Nigel
> > 
> > On Fri, 2003-07-18 at 08:06, Eric Altendorf wrote:
> > > I'm still running an old version swsusp so I apologize if this has 
> > > already been addressed, but I figured I'd just make mention of it.
> > > 
> > > If the laptop is resumed with a different A/C adaptor state (online 
> > > vs. offline) than when it was suspended, the /proc entry is 
> > incorrect 
> > > upon resume.  E.g., plug laptop in, suspend, unplug laptop, resume,
> > > /proc/acpi/ac_adapter/ADP1/state  reports still online until a 
> > > subsequent plug/unplug event.
> > > 
> > > Eric
> > > 
> > > 
> > > -------------------------------------------------------
> > > 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
> > > 
> > _______________________________________________
> > > swsusp-devel mailing list
> > > swsusp-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > https://lists.sourceforge.net/lists/listinfo/swsusp-devel
> > -- 
> > Nigel Cunningham
> > 495 St Georges Road South, Hastings 4201, New Zealand
> > 
> > You see, at just the right time, when we were still powerless,
> > Christ died for the ungodly.
> > 	-- Romans 5:6, NIV.
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> > _______________________________________________
> > 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: 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
> _______________________________________________
> swsusp-devel mailing list
> swsusp-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/swsusp-devel


-------------------------------------------------------
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

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

[Grover, Andrew]

Well we actually are calling the _PSR control method to implement the
"state" proc entry. Of course, that's just calling a control method so
who knows what the control method does -- I'd have to see what _PSR
looks like...can you get your dsdt from /proc/acpi/dsdt, disassemble
with iasl -d and post what _PSR is?

Thanks -- Regards -- Andy

> -----Original Message-----
> From: Nigel Cunningham [mailto:ncunningham-oKK1aGe2n869koe0gwxAeg@public.gmane.org] 
> Sent: Thursday, July 17, 2003 1:20 PM
> To: EricAltendorf-gZ4DH+Stb0k@public.gmane.org
> Cc: swsusp-devel; ACPI List
> Subject: [ACPI] Re: [Swsusp-devel] ACPI A/C adaptor status 
> not updated upon resume
> 
> 
> That's ACPI, not swsusp - it must be toggling the state based 
> on events,
> not actually detecting it.
> 
> Regards,
> 
> Nigel
> 
> On Fri, 2003-07-18 at 08:06, Eric Altendorf wrote:
> > I'm still running an old version swsusp so I apologize if this has 
> > already been addressed, but I figured I'd just make mention of it.
> > 
> > If the laptop is resumed with a different A/C adaptor state (online 
> > vs. offline) than when it was suspended, the /proc entry is 
> incorrect 
> > upon resume.  E.g., plug laptop in, suspend, unplug laptop, resume,
> > /proc/acpi/ac_adapter/ADP1/state  reports still online until a 
> > subsequent plug/unplug event.
> > 
> > Eric
> > 
> > 
> > -------------------------------------------------------
> > 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
> > 
> _______________________________________________
> > swsusp-devel mailing list
> > swsusp-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/swsusp-devel
> -- 
> Nigel Cunningham
> 495 St Georges Road South, Hastings 4201, New Zealand
> 
> You see, at just the right time, when we were still powerless,
> Christ died for the ungodly.
> 	-- Romans 5:6, NIV.
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> 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: 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