Method for resetting embedded controller?

Method for resetting embedded controller?

[Nigel Cunningham]

Hi.

I've been tracing the cause of keventd sometimes sucking all available
CPU after a suspend-to-disk (2.4.22). It seems that the embedded
controller in my Omnibook continally generates interrupts iif an ACPI
event occurs at the wrong time during the cycle (I haven't determined
when the critical time is yet). I'm therefore wondering if there is a
method whereby it can be reset or otherwise made to return to its normal
state.

I'm particularly noticing this when a lid event occurs during suspend,
whether or not button.o is insmod'd. If acpid is running, it shows
thousands of lid events per second. Another swsusp user has reported
similar issues.

Regards,

Nigel
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Evolution (n): A process whereby infinitely improbable events occur with
alarming frequency, order arises from chaos, and no one is given credit.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Method for resetting embedded controller?

[Karol Kozimor]

Thus wrote Nigel Cunningham:
> I'm particularly noticing this when a lid event occurs during suspend,
> whether or not button.o is insmod'd. If acpid is running, it shows
> thousands of lid events per second. Another swsusp user has reported
> similar issues.

I experienced the same problem a couple of times. I wouldn't really blame
lid, as I'm almost sure I had the lid event overflow when the lid button
was not touched at all during the cycle. From what I understand, the 
situation is connected with thermal zone handling, I can almost be sure
that if an active thermal trip point is hit during the resume process, the 
lid events will appear. I don't yet know if it's connected with bug #1185.

FYI:
1) There *was* something in swsusp code that caused keventd to spit those
   events at resume specifically when the lid was closed during suspend,
   but that was an ancient version of the code and AFAIR you fixed it right
   away,
2) I've had this problem occasionally occuring for months and I remember I
   once managed to calm keventd down by suspending and resuming again,
3) This may indeed be somehow related to swsusp, as the occurence rate of
   this problem has risen with recent versions of swsusp (but there's too
   many variables to confirm that and trying to reproduce the problem is a 
   tedious task).

Best regards,

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Method for resetting embedded controller?

[Karol Kozimor]

Thus wrote Karol Kozimor:
[...]

Oops, you were probably right to blame the lid event for that behaviour.
Closing the lid during suspend causes the keventd loop for me too (at least
for rc10F). We've had such a problem once, haven't we?
Best regards,

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Method for resetting embedded controller?

[Jan Rychter]

>>>>> "Karol" == Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>:
 Karol> Thus wrote Nigel Cunningham:
 >> I'm particularly noticing this when a lid event occurs during
 >> suspend, whether or not button.o is insmod'd. If acpid is running,
 >> it shows thousands of lid events per second. Another swsusp user has
 >> reported similar issues.

 Karol> I experienced the same problem a couple of times. I wouldn't
 Karol> really blame lid, as I'm almost sure I had the lid event
 Karol> overflow when the lid button was not touched at all during the
 Karol> cycle. From what I understand, the situation is connected with
 Karol> thermal zone handling, I can almost be sure that if an active
 Karol> thermal trip point is hit during the resume process, the lid
 Karol> events will appear. I don't yet know if it's connected with bug
 Karol> #1185.
[...]

FWIW, I've also been encountering this problem from time to time. It
seems to have subsided recently, for some reason.

I think I've even reported it here (ACPI list), but it got ignored (as
usual).

--J.


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com