AE_TIME on Operations in EC ( Embedded Controller ec.c )

AE_TIME on Operations in EC ( Embedded Controller ec.c )

[Dimitri Rebrikov]

Hi,

after i installed 2.4.22 on my Notebook i couldn't get
any battery information more. (i.e. nothing in /proc/acpi/battery)

BTW. I had no problem with ACPI before (2.4.18+ACPI and 2.4.20+ACPI)

The corresponding error message in log was:

Sep  5 12:49:57 mitnb kernel: evregion-0345: *** Error: Handler for [EmbeddedControl] returned AE_TIME
Sep  5 12:49:57 mitnb kernel:  psparse-1121: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node cee7cdc8), AE_TIME

Other embedded controls (i.e. thermal, fan etc) were not affected by this problem.

After some testing i located (i belief) the issue:
The values of ACPI_EC_UDELAY_COUNT and/or  ACPI_EC_UDELAY are too small
for my Hardware.

Here is the comparision between 2.4.20+ACPI and 2.4.22:

./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		1000	/* Poll @ 100us increments */
./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	10000	/* Wait 10ms max. during EC ops */

./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */

This means that the wait time for a EC operation in 2.4.22 was reduced with factor 100.

After i increase the value of ACPI_EC_UDELAY_COUNT to 10000
my problems gone. Now i can use the whole functionality of ACPI.

I don't know is there something in the ACPI specifikation defining max. wait time during EC op,
or the values in ec.c was investigated by testing.

My Hardware: (Clevo D270S Notebook, Pentium 4 M 1.8)
http://www.clevo.com.tw/products/D220S.asp

Regards
Dimitri



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: AE_TIME on Operations in EC ( Embedded Controller ec.c )

[Nate Lawson]

On Mon, 15 Sep 2003, Dimitri Rebrikov wrote:
> BTW. I had no problem with ACPI before (2.4.18+ACPI and 2.4.20+ACPI)
>
> The corresponding error message in log was:
>
> Sep  5 12:49:57 mitnb kernel: evregion-0345: *** Error: Handler for [EmbeddedControl] returned AE_TIME
> Sep  5 12:49:57 mitnb kernel:  psparse-1121: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node cee7cdc8), AE_TIME
>
> After some testing i located (i belief) the issue:
> The values of ACPI_EC_UDELAY_COUNT and/or  ACPI_EC_UDELAY are too small
> for my Hardware.
>
> Here is the comparision between 2.4.20+ACPI and 2.4.22:
>
> ./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		1000	/* Poll @ 100us increments */
> ./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	10000	/* Wait 10ms max. during EC ops */
>
> ./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
> ./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */
>
> This means that the wait time for a EC operation in 2.4.22 was reduced with factor 100.
>
> After i increase the value of ACPI_EC_UDELAY_COUNT to 10000
> my problems gone. Now i can use the whole functionality of ACPI.

I submitted that change in that the comment didn't match the code.  I've
found in FreeBSD that even 50 ms isn't enough sometimes so I suppose your
experience concurs with this.  You can probably bump it to 100 ms, just
make sure the comment matches the code.

BTW, there is no reason repsonses from the EC should be that slow.  I have
a feeling global lock contention is the real underlying problem.

-Nate


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: AE_TIME on Operations in EC ( Embedded Controller ec.c )

[Dimitri Rebrikov]

Nate Lawson wrote:
> On Mon, 15 Sep 2003, Dimitri Rebrikov wrote:
> 
>>BTW. I had no problem with ACPI before (2.4.18+ACPI and 2.4.20+ACPI)
>>
>>The corresponding error message in log was:
>>
>>Sep  5 12:49:57 mitnb kernel: evregion-0345: *** Error: Handler for [EmbeddedControl] returned AE_TIME
>>Sep  5 12:49:57 mitnb kernel:  psparse-1121: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node cee7cdc8), AE_TIME
>>
>>After some testing i located (i belief) the issue:
>>The values of ACPI_EC_UDELAY_COUNT and/or  ACPI_EC_UDELAY are too small
>>for my Hardware.
>>
>>Here is the comparision between 2.4.20+ACPI and 2.4.22:
>>
>>./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		1000	/* Poll @ 100us increments */
>>./linux-2.4.20/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	10000	/* Wait 10ms max. during EC ops */
>>
>>./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
>>./linux-2.4.22/drivers/acpi/ec.c:#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */
>>
>>This means that the wait time for a EC operation in 2.4.22 was reduced with factor 100.
>>
>>After i increase the value of ACPI_EC_UDELAY_COUNT to 10000
>>my problems gone. Now i can use the whole functionality of ACPI.
> 
> 
> I submitted that change in that the comment didn't match the code.  I've
> found in FreeBSD that even 50 ms isn't enough sometimes so I suppose your
> experience concurs with this.  You can probably bump it to 100 ms, just
> make sure the comment matches the code.
> 
> BTW, there is no reason repsonses from the EC should be that slow.  I have
> a feeling global lock contention is the real underlying problem.
> 
> -Nate
> 
Just now i have inspected the original acpi-patches for 2.4.18 and 2.4.20 and have realised that
the values of ACPI_EC_UDELAY and ACPI_EC_UDELAY_COUNT did not change in comparision with
kernel-2.4.22.
I recalled that I self made this changes at that time (Feb 2003) and forgotten to notice that. Sorry...

BTW I found the back posting with the same problem: http://sourceforge.net/mailarchive/message.php?msg_id=5608311
so i'm not alone have this problem.

IMHO The max. wait time is already 100ms because MaxWaitTime = ACPI_EC_UDELAY x ACPI_EC_UDELAY_COUNT
(i.e. 100us x 1000 = 100000us = 100ms)
But 100ms are obviously still too small for some harware (unfortunately my laptop inklusive).

How can i affect so that the value of ACPI_EC_UDELAY_COUNT will be increased in the kernel/acpi-sources?

If not the hardware but a global lock is the issue, how can it be solved?

Regards
Dimitri








-- 

------------------------------------------------------------------------
Dimitri Rebrikov
*T-Systems GEI GmbH*
Projektentwickler
Postanschrift: Prager Straße 15, D-04103 Leipzig
Telefon:         (0341) 1275-439
Telefax:         (0341) 1275-333
E-Mail:          Dimitri.Rebrikov-kyawv7ubMNaakBO8gow8eQ@public.gmane.org
<mailto:Dimitri.Rebrikov-kyawv7ubMNaakBO8gow8eQ@public.gmane.org>
Internet:         http://www.t-systems.com
------------------------------------------------------------------------



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf