https://bugzilla.kernel.org/show_bug.cgi?id=15895
--- Comment #22 from bugzillakernel...@lez.ath.cx 2010-11-09 01:43:18 ---
ok, i looked at latencytop last time this happened; and looked at the code
drivers/acpi/ec.c:
...
/* check if we received SCI during transaction */
ec_check_sci_sync(ec, acpi_ec_read_status(ec));
if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
msleep(1);
/* It is safe to enable the GPE outside of the transaction. */
acpi_enable_gpe(NULL, ec->gpe);
} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
pr_info(PREFIX "GPE storm detected, "
...
well, turns out the latency and the manner in which it is unresponsive is
closely related to the time in msleep (msec_to_jiffies + 1, then schedule slack
until the next wakeup)
you can force the bit and it exhibits the unresponsiveness that i opened the
bug for. if msleep could be factored out (i don't know how to do it myself, but
i'm investigating) then the responsiveness should be maintained. recently
Alexey Starikovskiy has been removed as the maintainer, apparently his email is
unreachable; so i haven't been able to figure out why the sleep is in there at
all
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
