Re: [Swsusp-devel] swsusp and ac status

Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

On Thu, 24 Jun 2004 14:33:44 +0200, Daniele Boffi <boffi-piYtxHxN1XRAly3Pu9w1wA@public.gmane.org> wrote:

> Hi,
> I noticed that a change in the ac status is not detected after a swsusp.
> I thought this was an acpi related and known issue; I sent a message
> to the acpi-devel list but with no significant answer.
>
> Is anybody aware of this problem? Is there any workaround available?
>
> How to reproduce the bad behavior:
>
> - swsuspend when on ac (resp. battery) power
> - unplug (resp. plug) the ac adapter when the laptop is off
> - resume when on battery (resp. ac) power
>
> Then /proc/acpi/ac_adapter/*/state says "on-line" (resp. "off-line").
> A new change in the status is then correctly detected.
>
> I tried different acpi configurations (ac in the kernel or as a module, unload
> the ac module before suspending and reload it after resuming...) with no
> success.
>
> actual kernel 2.6.7 (same behavior with previous ones), no acpi patch, swsusp2
> patch
>
> Compaq EVO N800v laptop.
>
> Same behavior with pm-suspend, swsusp and swsusp2.
>

The root cause is due to the AC module state at the time of suspend
being saved and restored on resume and thus being inconsistent
with the HW on resume which was "touched"  by the BIOS and resuming
kernel (the kernel which reads the image from disk) during its boot.

The problem affects all (2.4/2.6) kernels, most ACPI modules
(AC, Battery an Button seem especialy troublesome) and is due to lack of
PM support in the APCI subsystem.  A few users even reported crashes
on resume which went away when the modules were removed prior
to suspend.

The ACPI spec surely has standard methods for subsystem PM but these
are obviously not usable, whether due to being unimplemented or
broken in ACPI subsystem, DSTD or BIOS.

Guess the least the ACPI subsystem should  do is to disable relevant
modules on suspend event and reinit them in fashion similar to
boot on resume.

I personaly find it undesirable that  PM subsystem components have
no functioning PM :-(

For now, in practice all ACPI modules should be unloaded prior to
suspend and loaded on resume.

I use the AC module and kernel 2.4.24 with swsusp 2.0 and it works
fine as long as it is removed prior to suspend.

	Michael







-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: [Swsusp-devel] swsusp and ac status

[Daniele Boffi]

> For now, in practice all ACPI modules should be unloaded prior to
> suspend and loaded on resume.
> 
> I use the AC module and kernel 2.4.24 with swsusp 2.0 and it works
> fine as long as it is removed prior to suspend.

Unloading acpi modules, suspending, resuming and loading modules
again does not help for me (2.6.7 and swsusp 2.0.0.88).
Even after resuming, if I

rmmod ac
insmod ac

then I don't see the new charging state. On the other hand if, after 
resuming, I change the charging state again, then ac detection works 
OK.

I tried also with 2.4.25 and swsusp 2.0 ... then it is stranger: 

- suspend with ac plugged
- unplug
- resume
- ac is correctly detected off-line
- next changes in ac state are not detected


morph-XAiDara3MvRg9hUCZPvPmw@public.gmane.org said:
> Would you mind checking to see (with top or something) whether or
> not keventd is using 100% CPU next time this happens.

It is not. CPU is about 1% (mostly used by X)

Daniele




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

On Thu, 24 Jun 2004 17:13:51 +0200, Daniele Boffi <boffi-piYtxHxN1XRAly3Pu9w1wA@public.gmane.org> wrote:

>
>> For now, in practice all ACPI modules should be unloaded prior to
>> suspend and loaded on resume.
>>
>> I use the AC module and kernel 2.4.24 with swsusp 2.0 and it works
>> fine as long as it is removed prior to suspend.
>
> Unloading acpi modules, suspending, resuming and loading modules
> again does not help for me (2.6.7 and swsusp 2.0.0.88).
> Even after resuming, if I
>
> rmmod ac
> insmod ac

It is too late, it is already broken ;)

Please try:
rmmod AC
suspend/resume
modprobe AC

It should be OK...

>
> then I don't see the new charging state. On the other hand if, after
> resuming, I change the charging state again, then ac detection works
> OK.
>
> I tried also with 2.4.25 and swsusp 2.0 ... then it is stranger:
>
> - suspend with ac plugged
> - unplug
> - resume
> - ac is correctly detected off-line
> - next changes in ac state are not detected

Please proceed as above

>
>
> morph-XAiDara3MvRg9hUCZPvPmw@public.gmane.org said:
>> Would you mind checking to see (with top or something) whether or
>> not keventd is using 100% CPU next time this happens.
>
> It is not. CPU is about 1% (mostly used by X)
>

...As It is purely module related

	Michael


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Pavel Machek]

Hi!

> > For now, in practice all ACPI modules should be unloaded prior to
> > suspend and loaded on resume.
> > 
> > I use the AC module and kernel 2.4.24 with swsusp 2.0 and it works
> > fine as long as it is removed prior to suspend.
> 
> Unloading acpi modules, suspending, resuming and loading modules
> again does not help for me (2.6.7 and swsusp 2.0.0.88).
> Even after resuming, if I

This is known, and can be properly fixed by entering S4 (not S5;
during swsusp. Some more hacky solutions are available, too.
Get 2.6.7-vanilla and ask me for testing patch... 
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Pavel Machek]

Hi!

> > This is known, and can be properly fixed by entering S4 (not S5;
> > during swsusp. Some more hacky solutions are available, too.
> > Get 2.6.7-vanilla and ask me for testing patch... 
> 
> Yes, please. I find swsusp2 more reliable than pm-suspend and would 
> like to have it work correctly.

Here it is. Its for swsusp1, you'll have to port it to swsusp2
yourself. And its little... "interesting".
							Pavel

Index: linux/kernel/power/swsusp.c
===================================================================
--- linux.orig/kernel/power/swsusp.c	2004-06-22 12:53:19.000000000 +0200
+++ linux/kernel/power/swsusp.c	2004-06-27 18:25:28.000000000 +0200
@@ -750,6 +759,11 @@
 	update_screen(fg_console);
 	release_console_sem();
 #endif
+
+#ifdef CONFIG_ACPI_SLEEP
+	acpi_leave_sleep_state(5);	/* This is "interesting". We need to call _WAK due to HP nx5000,
+					   but we really should make this normal S4 support. */
+#endif
 }
 
 /* do_magic() is implemented in arch/?/kernel/suspend_asm.S, and basically does:



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


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Daniele Boffi]

> Perhaps the ACPI people could advise how to increase debug verbosity
> to see what happens or if that can't be done, put some printks into AC
> module to see what happens when the module is loaded on resume.

I am ready to run any test you propose!

Daniele




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Stefan Seyfried]

On Fri, Jun 25, 2004 at 07:29:51PM +0800, Michael Frank wrote:

> >It is NOT in my case. It is one of the first things I did. Now, just
> >in case, I gave it another try, but it does not work.
> >
> >modprobe -r ac
> >suspend
> >unplug
> >resume
> >modprobe ac
> >
> >cat /proc/acpi/ac_adapter/C131/state
> >state: on-line
> >
> >If now, after resuming, I plug and unplug the adapter...
> >
> >cat /proc/acpi/ac_adapter/C131/state
> >state: off-line

I have exactly the same on a hp compaq nx 5000.

> Too bad, this implies that the AC module does not get reinitialized after
> resume and I suspect that acpi core is broken on 2.6 in this regard.

Pavel and i and some HP BIOS engineers analyzed this problem and pavel
proposed an ugly hack in his swsusp code to work around this. I have
to check back in my archives / bugzilla reports for this.
The funny thing is, that the BIOS is 100% correct and this leads to this
problem (at least that was what Pavel concluded). HP would have changed
the BIOS to work around the linux bug, but this would be even more ugly.
I will dig my archives for more info and a (probably ugly, but maybe
somehow working) patch. I'm offline on the train now, so this will have
to wait until monday.
 
> I'll compile 2.6 and try it on my HW.

It is completely hardware dependent, i only saw it on the nx5000 up to
now.

> Perhaps the ACPI people could advise how to increase debug verbosity
> to see what happens or if that can't be done, put some printks into AC
> module to see what happens when the module is loaded on resume.

I am not even sure that the AC module is to blame, i have to check
my archives, i don't remember all the gory details.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: swsusp and ac status

[Micha Feigin]

On Fri, Jun 25, 2004 at 03:14:22PM -0000, Stefan Seyfried wrote:
> On Fri, Jun 25, 2004 at 07:29:51PM +0800, Michael Frank wrote:
> 
> > >It is NOT in my case. It is one of the first things I did. Now, just
> > >in case, I gave it another try, but it does not work.
> > >
> > >modprobe -r ac
> > >suspend
> > >unplug
> > >resume
> > >modprobe ac
> > >
> > >cat /proc/acpi/ac_adapter/C131/state
> > >state: on-line
> > >
> > >If now, after resuming, I plug and unplug the adapter...
> > >
> > >cat /proc/acpi/ac_adapter/C131/state
> > >state: off-line
> 
> I have exactly the same on a hp compaq nx 5000.
> 
> > Too bad, this implies that the AC module does not get reinitialized after
> > resume and I suspect that acpi core is broken on 2.6 in this regard.
> 
> Pavel and i and some HP BIOS engineers analyzed this problem and pavel
> proposed an ugly hack in his swsusp code to work around this. I have
> to check back in my archives / bugzilla reports for this.
> The funny thing is, that the BIOS is 100% correct and this leads to this
> problem (at least that was what Pavel concluded). HP would have changed
> the BIOS to work around the linux bug, but this would be even more ugly.
> I will dig my archives for more info and a (probably ugly, but maybe
> somehow working) patch. I'm offline on the train now, so this will have
> to wait until monday.
>  
> > I'll compile 2.6 and try it on my HW.
> 
> It is completely hardware dependent, i only saw it on the nx5000 up to
> now.

Also saw this on a sony vaio pcg-fxa53 (via + amd 1300+)
> 
> > Perhaps the ACPI people could advise how to increase debug verbosity
> > to see what happens or if that can't be done, put some printks into AC
> > module to see what happens when the module is loaded on resume.
> 
> I am not even sure that the AC module is to blame, i have to check
> my archives, i don't remember all the gory details.

For me compiling battery as a module and unloading/swsusp/resume
bypasses the problem.

> -- 
> Stefan Seyfried
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>  
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.
> 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Karol Kozimor]

Thus wrote Michael Frank:
> Too bad, this implies that the AC module does not get reinitialized after
> resume and I suspect that acpi core is broken on 2.6 in this regard.

As far as I know, there is no need to reinitialize the AC module, as it
does not cache the results -- upon read, it calls the appropriate _PSR
method which is supposed to return the correct AC adapter state, as simple
as it gets. This way, any problems would indicate a faulty BIOS.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

On Mon, 28 Jun 2004 00:28:42 +0200, Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> wrote:

> Thus wrote Michael Frank:
>> Too bad, this implies that the AC module does not get reinitialized after
>> resume and I suspect that acpi core is broken on 2.6 in this regard.
>
> As far as I know, there is no need to reinitialize the AC module, as it
> does not cache the results -- upon read, it calls the appropriate _PSR
> method which is supposed to return the correct AC adapter state, as simple
> as it gets. This way, any problems would indicate a faulty BIOS.
> Best regards,
>

Sorry, the BIOS does not know about suspend.

Please consider It just booted cold and the resuming kernel
without any ACPI modules won't have touched the AC method.

----> Thus the BIOS is now in a post boot state, like before
	vmlinux starts on boot!

----> The resumed kernel is in the state it was upon suspend.

Therefor IMO cause is the kernel which was resumed and
continues to talk to the BIOS which is in a state quite different
than what it was pefore suspend...

I concur that the BIOS in this case may break, but as it worked
prior to suspend it cannot be blamed for not handling such abuse.

A simple solution is for the resumed kernel to  start talking to
BIOS as it would have on a normal boot, perhaps executing
just a subset of the init code.

If it also would disable all modules prior to suspend, it
would likely fix all problems eliminating the reuqirement
to unload ACPI modules....

Best Regards



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

On Mon, 28 Jun 2004 08:13:00 +0800, Michael Frank <mhf-jjFNsPSvq+iXDw4h08c5KA@public.gmane.org> wrote:

> On Mon, 28 Jun 2004 00:28:42 +0200, Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> wrote:
>
>> Thus wrote Michael Frank:
>>> Too bad, this implies that the AC module does not get reinitialized after
>>> resume and I suspect that acpi core is broken on 2.6 in this regard.
>>
>> As far as I know, there is no need to reinitialize the AC module, as it
>> does not cache the results -- upon read, it calls the appropriate _PSR
>> method which is supposed to return the correct AC adapter state, as simple
>> as it gets. This way, any problems would indicate a faulty BIOS.
>> Best regards,
>>
>
> Sorry, the BIOS does not know about suspend.
>
> Please consider It just booted cold and the resuming kernel
> without any ACPI modules won't have touched the AC method.
>
> ----> Thus the BIOS is now in a post boot state, like before
> 	vmlinux starts on boot!

To clarify

  ----> Thus the BIOS is now in a post boot state, like _after_
  	vmlinux started on boot! and BIOS AC adapter interface
	is unchanged from pre-boot.
>
> ----> The resumed kernel is in the state it was upon suspend.
>
> Therefor IMO cause is the kernel which was resumed and
> continues to talk to the BIOS which is in a state quite different
> than what it was pefore suspend...
>
> I concur that the BIOS in this case may break, but as it worked
> prior to suspend it cannot be blamed for not handling such abuse.
>
> A simple solution is for the resumed kernel to  start talking to
> BIOS as it would have on a normal boot, perhaps executing
> just a subset of the init code.
>
> If it also would disable all modules prior to suspend, it
> would likely fix all problems eliminating the reuqirement
> to unload ACPI modules....
>
> Best Regards
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
>




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Karol Kozimor]

Thus wrote Michael Frank:
> >----> Thus the BIOS is now in a post boot state, like before
> >	vmlinux starts on boot!
> 
> To clarify
> 
>  ----> Thus the BIOS is now in a post boot state, like _after_
>  	vmlinux started on boot! and BIOS AC adapter interface
> 	is unchanged from pre-boot.

Please supply your DSDT to verify what's exactly going on there.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

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

On Mon, 28 Jun 2004 07:27:04 +0200, Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> wrote:

> Thus wrote Michael Frank:
>> >----> Thus the BIOS is now in a post boot state, like before
>> >	vmlinux starts on boot!
>>
>> To clarify
>>
>>  ----> Thus the BIOS is now in a post boot state, like _after_
>>  	vmlinux started on boot! and BIOS AC adapter interface
>> 	is unchanged from pre-boot.
>
> Please supply your DSDT to verify what's exactly going on there.
> Best regards,
>

Enclosed.
Best regards,

[-- Attachment #2: dsdt.bz2 --]
[-- Type: application/bzip2, Size: 5745 bytes --]

Re: [ACPI] Re: swsusp and ac status

[Pavel Machek]

Hi!

> >As far as I know, there is no need to reinitialize the AC module, as 
> >it
> >does not cache the results -- upon read, it calls the appropriate 
> >_PSR
> >method which is supposed to return the correct AC adapter state, as 
> >simple
> >as it gets. This way, any problems would indicate a faulty BIOS.
> >Best regards,
> >
> 
> Sorry, the BIOS does not know about suspend.

Hacky solution is to call _WAK so that BIOS updates is caches...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Daniele Boffi]

> 
> Please try:
> rmmod AC
> suspend/resume
> modprobe AC
> 
> It should be OK...

It is NOT in my case. It is one of the first things I did. Now, just 
in case, I gave it another try, but it does not work.

modprobe -r ac
suspend
unplug
resume
modprobe ac

cat /proc/acpi/ac_adapter/C131/state
state: on-line

If now, after resuming, I plug and unplug the adapter...

cat /proc/acpi/ac_adapter/C131/state
state: off-line

> 2.0.0.88 is the most successful one in the whole 2.6 series.

I agree! besides this ac problem (and a little typo in the version 
number that reads 86 instead of 88...) it works great.

Daniele




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Nigel Cunningham]

Hi.

On Fri, 2004-06-25 at 17:01, Daniele Boffi wrote:

> > 2.0.0.88 is the most successful one in the whole 2.6 series.
> 
> I agree! besides this ac problem (and a little typo in the version 
> number that reads 86 instead of 88...) it works great.

:> Forgot to update the version number.

Regards,

Nigel



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Michael Frank]

On Fri, 25 Jun 2004 09:01:15 +0200, Daniele Boffi <boffi-piYtxHxN1XRAly3Pu9w1wA@public.gmane.org> wrote:

>>
>> Please try:
>> rmmod AC
>> suspend/resume
>> modprobe AC
>>
>> It should be OK...
>
> It is NOT in my case. It is one of the first things I did. Now, just
> in case, I gave it another try, but it does not work.
>
> modprobe -r ac
> suspend
> unplug
> resume
> modprobe ac
>
> cat /proc/acpi/ac_adapter/C131/state
> state: on-line
>
> If now, after resuming, I plug and unplug the adapter...
>
> cat /proc/acpi/ac_adapter/C131/state
> state: off-line
>

Too bad, this implies that the AC module does not get reinitialized after
resume and I suspect that acpi core is broken on 2.6 in this regard.

I'll compile 2.6 and try it on my HW.

Perhaps the ACPI people could advise how to increase debug verbosity
to see what happens or if that can't be done, put some printks into AC
module to see what happens when the module is loaded on resume.

	Michael



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [Swsusp-devel] swsusp and ac status

[Micha Feigin]

On Fri, Jun 25, 2004 at 01:26:28AM +0800, Michael Frank wrote:
> On Thu, 24 Jun 2004 17:13:51 +0200, Daniele Boffi <boffi-piYtxHxN1XRAly3Pu9w1wA@public.gmane.org> 
> wrote:
> 
> >
> >>For now, in practice all ACPI modules should be unloaded prior to
> >>suspend and loaded on resume.
> >>
> >>I use the AC module and kernel 2.4.24 with swsusp 2.0 and it works
> >>fine as long as it is removed prior to suspend.
> >
> >Unloading acpi modules, suspending, resuming and loading modules
> >again does not help for me (2.6.7 and swsusp 2.0.0.88).
> >Even after resuming, if I
> >
> >rmmod ac
> >insmod ac
> 
> It is too late, it is already broken ;)
> 

Also try instead of ac to remove and load battery
> Please try:
> rmmod AC
> suspend/resume
> modprobe AC
> 

rmmod battery
suspend/resume
modprobe battery

> It should be OK...
> 
> >
> >then I don't see the new charging state. On the other hand if, after
> >resuming, I change the charging state again, then ac detection works
> >OK.
> >
> >I tried also with 2.4.25 and swsusp 2.0 ... then it is stranger:
> >
> >- suspend with ac plugged
> >- unplug
> >- resume
> >- ac is correctly detected off-line
> >- next changes in ac state are not detected
> 
> Please proceed as above
> 
> >
> >
> >morph-XAiDara3MvRg9hUCZPvPmw@public.gmane.org said:
> >>Would you mind checking to see (with top or something) whether or
> >>not keventd is using 100% CPU next time this happens.
> >
> >It is not. CPU is about 1% (mostly used by X)
> >
> 
> ...As It is purely module related
> 
> 	Michael
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
> 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com