http://bugzilla.kernel.org/show_bug.cgi?id=11896
------- Comment #21 from [EMAIL PROTECTED] 2008-11-04 08:15 ------- a. AE_TIME issue that happens on Asus EEEPC & HP box I raise the AE_TIME issue about your patch. In fact I repeated my viewpoint several times about this issue.Why AE_TIME happens on Asus EEEPC & HP box is consistent with my analysis. The discussion can be found in : >http://marc.info/?l=linux-acpi&m=122103582406176&w=2 b. msleep is replaced by udelay(in comment #14) When there is no EC interrupt confirm in EC transaction or EC GPE storm is detected, it will be switched to polling mode.In such case the EC transaction will be done in the function of ec_poll. In the following EC transactions the CPU will do nothing but loop while waiting for the EC status. In such case the performance will be affected. At the same time the CPU can't enter idle state, which causes that more power is used. In fact the udelay is replaced by the msleep in the following commit: >commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a >Author: Alexey Starikovskiy <[EMAIL PROTECTED]> >Date: Fri Jun 6 11:49:33 2008 -0400 >ACPI: EC: Use msleep instead of udelay while waiting for event. >http://bugzilla.kernel.org/show_bug.cgi?id=10724 In the above commit there is no explanation why udelay is replaced msleep. Now when the problem appears, the commit is reverted again before getting the root cause. To let more people be involved in the bug fix about EC, IMO it is very important to add the detailed explanation. Only when there is no other way to solve the problem, it is reasonable to consider reverting the commit. c. Why say that I waste your time? I know that you can write the patch very quickly. But sometimes there are too many errors after you sent your patch to ACPI mailing list. For example: There exists the fatal sync issue in the patch you pasted in http://bugzilla.kernel.org/show_bug.cgi?id=11549#C1. >http://marc.info/?l=linux-acpi&m=122164185131664&w=2 If no one raises any issue about your patch, more laptops will be broken by your patch. Even although someone raise some issues about your patch, there still exists another issue. For example: There exist a bunch of the following warning message in bug 11930: > ACPI: EC: non-query interrupt received, switching to interrupt mode > __ratelimit: 40 callbacks suppressed It is harmless but it is confusing and annoying. d. About the patch set from me 1)The EC transaction is done in process context. Maybe it is slow but it will be more stable. At the same time compared with the 2.6.26 kernel it is not changed too lot. 2)Add 2us delay before checking EC status while in polling mode. 3)Add the delay to work around the EC GPE storm. This only affects some broken laptops. It will also be OK to disable EC GPE while doing EC transaction after EC GPE storm is detected. But it is possible to lose the EC notification event while doing EC transaction. So to avoid losing the EC notification event the udelay is added to workaround the EC GPE storm. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
