From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dimitri Rebrikov Subject: Re: AE_TIME on Operations in EC ( Embedded Controller ec.c ) Date: Tue, 16 Sep 2003 14:32:56 +0200 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <3F6702F8.5020808@t-systems.com> References: <3F657BDB.9080805@t-systems.com> <20030915135247.H6780@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-path: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.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 Internet: http://www.t-systems.com ------------------------------------------------------------------------ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf