ACPI - SWSUSP interaction

ACPI - SWSUSP interaction

[Rob Miller]

Hi,

I am a happy user of both the ACPI and SWSUSP patches; I'm currently still
on acpi-20030328 applied to 2.4.21-rc1 as the latest SWSUSP patch
(19-27) isn't playing well for me with acpi-20030424.

In any event, I think there is an issue that one or more folk here may be
able to help with.  It appears to me that reads of at least the following
/proc entries do not actually test the hardware state, but rely on
detecting ACPI events to trigger changes in stored information:

/proc/acpi/ac_adapter/ADP1/state
/proc/acpi/battery/BAT1/state: capacity state, charging state

I base this on observing that these entries do not change to reflect
removal/insertion of the AC plug on my Toshiba Satellite 5100 laptop
during a suspend.  This caused minor but not insurmountable problems for
writing a battery monitoring daemon which hibernates the machine when the
battery goes too low, as it was difficult to determine when powering back
on that there was no need to immediately hibernate again.

I find these results with the ACPI code compiled-in and as modules.  When
built as modules, on loading during or after the resume without an
additional plug-change they report the wrong state -- e.g.:

ACPI: AC Adapter [ADP1] (off-line)

rmmod - plug - modprobe of ac.o while powered on of course gets the right
state, but I expect this is because the in-kernel ACPI code is running and
gets the ACPI event.

Question 1:  Is my conclusion above accurate, or have I run into an
idiosyncrasy of the laptop?  Certainly it gets the correct reading if I
shutdown - plug in - boot the device.

Question 2:  if it is the case that these /proc entries are only updated
on specific ACPI events, can I 
 (a) get the world changed such that reads of the /proc entries cause
    an actual re-read of the hardware status?
 (b) get the world changed so that the hardware status is re-read on 
    loading the ACPI modules?
 (c) simulate (an) ACPI event(s) in software to cause the hardware status 
    to be re-read?
 (d) implement another solution I haven't thought of yet?

Thanks for any suggestions.

best,

rob.






-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ACPI - SWSUSP interaction

[Stephan Krings]

Hi,

> In any event, I think there is an issue that one or more folk here may be
> able to help with.  It appears to me that reads of at least the following
> /proc entries do not actually test the hardware state, but rely on
> detecting ACPI events to trigger changes in stored information:

[ ... ]

> Question 1:  Is my conclusion above accurate, or have I run into an
> idiosyncrasy of the laptop?

No, I can confirm your observation. I'm also using both ACPI and the
swsusp patches for 2.4. When the machine is suspended and the AC
adapter changes state, this change will not be recognized upon resume.

I'd guess that the ACPI code stores the state somewhere in memory and
will only change it, when the ACPI BIOS generates events.

I think the ACPI code should just reexamine some values after
resume. This will require quite a lot of integration between swsusp
and ACPI and I'm not sure, if this integration is already present.

Regards,

Stephan



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ACPI - SWSUSP interaction

[Nigel Cunningham]

Hi.

There's no interaction between swsusp and ACPI at present. Neither, I
believe, should there be (2.5 is a different story, since it has the
driver model). If it's possible for ACPI to properly check the status
(and I'd be surprised if its not possible), it should do so rather than
storing the state in a variable. Since its not done in this way at the
moment, I'd _assume_ some deficiency(sp?) in the ACPI spec (rather than
that Andy et al have tried to take a shortcut) or that it's done this
way as an optimisation.

Regards,

Nigel

On Thu, 2003-05-08 at 18:58, Stephan Krings wrote:
> Hi,
> 
> > In any event, I think there is an issue that one or more folk here may be
> > able to help with.  It appears to me that reads of at least the following
> > /proc entries do not actually test the hardware state, but rely on
> > detecting ACPI events to trigger changes in stored information:
> 
> [ ... ]
> 
> > Question 1:  Is my conclusion above accurate, or have I run into an
> > idiosyncrasy of the laptop?
> 
> No, I can confirm your observation. I'm also using both ACPI and the
> swsusp patches for 2.4. When the machine is suspended and the AC
> adapter changes state, this change will not be recognized upon resume.
> 
> I'd guess that the ACPI code stores the state somewhere in memory and
> will only change it, when the ACPI BIOS generates events.
> 
> I think the ACPI code should just reexamine some values after
> resume. This will require quite a lot of integration between swsusp
> and ACPI and I'm not sure, if this integration is already present.
> 
> Regards,
> 
> Stephan
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Be diligent to present yourself approved to God as a workman who does
not need to be ashamed, handling accurately the word of truth.
	-- 2 Timothy 2:14, NASB.



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com