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

[Dimitri Rebrikov <dimitri.rebrikov-kyawv7ubMNaakBO8gow8eQ@public.gmane.org>]

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