From: Lv Zheng <lv.zheng@intel.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>
Cc: Lv Zheng <lv.zheng@intel.com>, Lv Zheng <zetalog@gmail.com>,
<linux-kernel@vger.kernel.org>,
linux-acpi@vger.kernel.org
Subject: [RFC PATCH v3 00/14] ACPI/EC: Add event storm prevention and cleanup command storm prevention.
Date: Mon, 21 Jul 2014 14:04:51 +0800 [thread overview]
Message-ID: <cover.1405922585.git.lv.zheng@intel.com> (raw)
In-Reply-To: <cover.1403060601.git.lv.zheng@intel.com>
Note that this patchset is very stable now, it is sent as RFC because it
depends on an ACPICA GPE enhancement series which might be merged from
ACPICA upstream.
This patchset is based on the previous ACPI/EC bug fixes series and the GPE
API enhancement series.
For the EC driver, GPE must be disabled to prevent the following storms:
1. Command errors:
If there are too many IRQs coming during a command processing period and
such IRQs are not related to the event (EVT_SCI),
acpi_set_gpe(ACPI_GPE_DISABLE) is invoked to prevent further storms
during the same command transaction. This is not implemented in a good
style. Ideally, we should only enable storm prevention for the current
command so that the next command can try the efficient interrupt mode
again.
This patchset enhances this storm prevention (PATCH 01, 03-04).
2. Event errors:
There are cases that BIOS doesn't provide a _Qxx method for the returned
xx query value, in this case, acpi_set_gpe(ACPI_GPE_DISABLE) need to be
invoked to prevent event IRQ storms. This case is detected during the EC
bug fix:
https://bugzilla.kernel.org/show_bug.cgi?id=70891
There is a dmesg showing a 0x0D query storm, for which there is no _Q0D
method provided by the ACPI table to handle (comment 55), this becomes a
GPE storm and slows down the machine a lot, it takes longer time for
Linux to complete the bootup (comment 80).
This patchset implements such storm prevention (PATCH 06-07 10-11),
turning EC driver into the polling mode when the storm happens so that
other tasks can be processed by the CPU without being affected by this
GPE storm.
3. Pending events:
Though GPE is edge triggered, the underlying firmware may maliciously
trigger GPE when IRQ is indicated. This makes EC GPE more like a level
triggered interrupt. In case of event (EVT_SCI), since the Linux EC
driver responses it (using QR_EC command) in the task context with the
GPE enabled, there are chances for a GPE storm to occur before QR_EC is
executed.
A common solution is to implement an IRQ context QR_EC issuing, this is
also a must-take step to convert the EC GPE handler into the threaded
IRQ model. The above bug link contains a prototype to achieve this, but
it fails to pass the suspend/resume tests. And the reporter shows a case
that user commands need to be executed while EVT_SCI is indicated
because _Qxx method evaluation requires normal EC command to be executed
by the EC driver to complete the event (EVT_SCI) handling. Without
further investigation in ACPICA to see if this evaluation will block the
event handler, it is better to keep the current proven task context
style QR_EC issuing to allow user commands to compete with QR_EC to be
executed. I'll try IRQ mode QR_EC issuing later using another patch
series.
If we still want to keep the task context responding logic, for such EC
hardware/firmware, acpi_set_gpe(ACPI_GPE_DISABLE) should be invoked
after EVT_SCI interrupt is indicated and acpi_set_gpe(ACPI_GPE_ENABLE)
should be invoked before the first step of QR_EC has taken place.
Since there is no real cases are reported, this patchset doesn't
introduce such storm prevention, but only makes it possible to implement
this for such platform by invoking acpi_enable_gpe() when EVT_SCI is
detected and decreasing the GPE reference after QR_EC command is issued
(PATCH 10), acpi_set_gpe() can be invoked between them as a quirk for
such platforms. This facility has passed the unit tests of system
suspend/resume flushing, in such cases all EC IRQs are polled by the
task context waiters.
All of the above storm prevention supports are implemented using the ideal
GPE handling model provided by the previous GPE API enhancement series.
This patchset also contains an EC commands flushing support. By
implementing EC commands flushing, we now achieve an additional benefit:
Some EC driven ACPI devices may require all submitted EC commands to be
completed before they can be safely suspended or unplugged. Otherwise the
state of such devices will be broken.
The refined patches are also passed the runtime/suspend tests carried out
on the following platforms:
"Dell Inspiron Mini 1010" - i386 kernel
"Dell Latitude 6430u" - x86_64 kernel
This patchset also includes a unit test facility, I used it to test the
hotplug support code in the driver. It's useful for future EC development.
Lv Zheng (14):
ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.
ACPI/EC: Add detailed command/query debugging information.
ACPI/EC: Cleanup command storm prevention using the new GPE handling
model.
ACPI/EC: Refine command storm prevention support.
ACPI/EC: Add reference counting for query handlers.
ACPI/EC: Add command flushing support.
ACPI/EC: Add a warning message to indicate event storms.
ACPI/EC: Refine event/query debugging messages.
ACPI/EC: Add CPU ID to debugging messages.
ACPI/EC: Cleanup QR_SC command processing by adding a kernel thread
to poll EC events.
ACPI/EC: Add event storm prevention support.
ACPI/EC: Add GPE reference counting debugging messages.
ACPI/EC: Add unit test support for EC driver hotplug.
ACPI/EC: Cleanup coding style.
drivers/acpi/ec.c | 566 ++++++++++++++++++++++++++++++++++++++---------
drivers/acpi/internal.h | 3 +
2 files changed, 462 insertions(+), 107 deletions(-)
--
1.7.10
next prev parent reply other threads:[~2014-07-21 6:05 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 3:17 [PATCH 0/9] ACPI/EC: Improve GPE handling model Lv Zheng
2014-06-18 3:17 ` [PATCH 1/9] ACPICA: Events: Reduce indent divergences of events files Lv Zheng
2014-06-18 3:17 ` [PATCH 2/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in atomic context Lv Zheng
2014-06-18 3:17 ` [PATCH 3/9] ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences Lv Zheng
2014-06-18 3:17 ` [PATCH 4/9] ACPICA: Events: Remove acpi_ev_enable_gpe() Lv Zheng
2014-06-18 3:17 ` [PATCH 5/9] ACPICA: Events: Reduce divergences to honor notify handler enabled GPEs Lv Zheng
2014-06-18 3:17 ` [PATCH 6/9] ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag Lv Zheng
2014-06-18 3:18 ` [PATCH 7/9] ACPI/EC: Add detailed command/query debugging information Lv Zheng
2014-06-18 3:18 ` [PATCH 8/9] ACPI/EC: Deploy the new GPE handling model Lv Zheng
2014-06-18 3:18 ` [PATCH 9/9] ACPI/EC: Add unit test support for EC driver hotplug Lv Zheng
2014-07-15 3:07 ` [PATCH v2 0/9] ACPICA: Improve GPE handling model Lv Zheng
2014-07-15 3:07 ` [PATCH v2 1/9] ACPICA: Events: Reduce indent divergences of events files Lv Zheng
2014-07-15 3:07 ` [PATCH v2 2/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in atomic context Lv Zheng
2014-07-15 3:07 ` [PATCH v2 3/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in deferred handlers Lv Zheng
2014-07-15 3:07 ` [PATCH v2 4/9] ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences Lv Zheng
2014-07-15 3:07 ` [PATCH v2 5/9] ACPICA: Events: Fix an issue that acpi_set_gpe() cannot unconditionally enable GPEs Lv Zheng
2014-07-15 3:07 ` [PATCH v2 6/9] ACPICA: Events: Fix an issue that status of GPEs are unexpectedly cleared Lv Zheng
2014-07-15 3:07 ` [PATCH v2 7/9] ACPICA: Events: Fix an issue that originally_enabled check is not paired Lv Zheng
2014-07-15 3:08 ` [PATCH v2 8/9] ACPICA: Events: Add a flag to disable internal auto GPE clearing Lv Zheng
2014-07-15 3:08 ` [PATCH v2 9/9] ACPI: Update interrupt handler to honor new ACPI_REENABLE_GPE bit Lv Zheng
2014-07-15 12:25 ` [PATCH v2 0/9] ACPICA: Improve GPE handling model Rafael J. Wysocki
2014-07-16 0:36 ` Zheng, Lv
2014-07-15 3:14 ` [PATCH v2 00/10] ACPI/EC: Add event storm prevention and cleanup command storm prevention Lv Zheng
2014-07-15 3:14 ` [PATCH v2 01/10] ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag Lv Zheng
2014-07-15 3:14 ` [PATCH v2 02/10] ACPI/EC: Add detailed command/query debugging information Lv Zheng
2014-07-15 3:14 ` [PATCH v2 03/10] ACPI/EC: Deploy the new GPE handling model Lv Zheng
2014-07-15 3:14 ` [PATCH v2 04/10] ACPI/EC: Refine command storm prevention support Lv Zheng
2014-07-15 3:14 ` [PATCH v2 05/10] ACPI/EC: Add reference counting for query handlers Lv Zheng
2014-07-15 3:15 ` [PATCH v2 06/10] ACPI/EC: Add a warning message to indicate event storms Lv Zheng
2014-07-15 3:15 ` [PATCH v2 07/10] ACPI/EC: Refine event/query debugging messages Lv Zheng
2014-07-15 3:15 ` [PATCH v2 08/10] ACPI/EC: Add command flushing support Lv Zheng
2014-07-15 3:15 ` [PATCH v2 09/10] ACPI/EC: Add event storm prevention support Lv Zheng
2014-07-15 3:15 ` [PATCH v2 10/10] ACPI/EC: Add unit test support for EC driver hotplug Lv Zheng
2014-07-15 7:09 ` [PATCH v2] ACPI/EC: Enable storm prevention mechanisms Lv Zheng
2014-07-16 0:44 ` Andi Kleen
2014-07-16 0:55 ` Zheng, Lv
2014-07-21 6:04 ` Lv Zheng [this message]
2014-07-21 6:05 ` [RFC PATCH v3 01/14] ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 02/14] ACPI/EC: Add detailed command/query debugging information Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 03/14] ACPI/EC: Cleanup command storm prevention using the new GPE handling model Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 04/14] ACPI/EC: Refine command storm prevention support Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 05/14] ACPI/EC: Add reference counting for query handlers Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 06/14] ACPI/EC: Add command flushing support Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 07/14] ACPI/EC: Add a warning message to indicate event storms Lv Zheng
2014-07-21 6:05 ` [RFC PATCH v3 08/14] ACPI/EC: Refine event/query debugging messages Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 09/14] ACPI/EC: Add CPU ID to " Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 10/14] ACPI/EC: Cleanup QR_SC command processing by adding a kernel thread to poll EC events Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 11/14] ACPI/EC: Add event storm prevention support Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 12/14] ACPI/EC: Add GPE reference counting debugging messages Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 13/14] ACPI/EC: Add unit test support for EC driver hotplug Lv Zheng
2014-07-21 6:06 ` [RFC PATCH v3 14/14] ACPI/EC: Cleanup coding style Lv Zheng
2014-07-22 1:11 ` [RFC PATCH v3 00/14] ACPI/EC: Add event storm prevention and cleanup command storm prevention Rafael J. Wysocki
2014-07-22 1:25 ` Zheng, Lv
2014-07-22 22:15 ` Rafael J. Wysocki
2014-07-23 1:31 ` Zheng, Lv
2015-02-05 8:24 ` [PATCH v4 0/6] ACPI / EC: Fix GPE handling related races Lv Zheng
2015-02-05 8:27 ` [PATCH v4 1/6] ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs Lv Zheng
2015-02-05 8:27 ` [PATCH v4 2/6] ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences Lv Zheng
2015-02-05 8:27 ` [PATCH v4 3/6] ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model Lv Zheng
2015-02-05 8:27 ` [PATCH v4 4/6] ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode Lv Zheng
2015-02-05 8:27 ` [PATCH v4 5/6] ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp Lv Zheng
2015-02-05 8:27 ` [PATCH v4 6/6] ACPI / EC: Update revision due to raw handler mode Lv Zheng
2015-02-05 15:19 ` [PATCH v4 0/6] ACPI / EC: Fix GPE handling related races Rafael J. Wysocki
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=cover.1405922585.git.lv.zheng@intel.com \
--to=lv.zheng@intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=zetalog@gmail.com \
/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