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

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

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

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:          [email protected]
<mailto:[email protected]>
Internet:         http://www.t-systems.com
------------------------------------------------------------------------



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