From: Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org>
To: Dimitri Rebrikov
<dimitri.rebrikov-kyawv7ubMNaakBO8gow8eQ@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: AE_TIME on Operations in EC ( Embedded Controller ec.c )
Date: Mon, 15 Sep 2003 13:54:51 -0700 (PDT) [thread overview]
Message-ID: <20030915135247.H6780@root.org> (raw)
In-Reply-To: <3F657BDB.9080805-kyawv7ubMNaakBO8gow8eQ@public.gmane.org>
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
next prev parent reply other threads:[~2003-09-15 20:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-15 8:44 AE_TIME on Operations in EC ( Embedded Controller ec.c ) Dimitri Rebrikov
[not found] ` <3F657BDB.9080805-kyawv7ubMNaakBO8gow8eQ@public.gmane.org>
2003-09-15 20:54 ` Nate Lawson [this message]
2003-09-16 12:32 ` Dimitri Rebrikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030915135247.H6780@root.org \
--to=nate-y6vguytwhu0@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=dimitri.rebrikov-kyawv7ubMNaakBO8gow8eQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox