Re: [PATCH v2 0/5] ACPI / EC: Add reference counting for requests and cleans up the grace periods support.

From: Rafael J. Wysocki
Date: Wed Feb 11 2015 - 20:17:51 EST


On 2/9/2015 3:23 AM, Zheng, Lv wrote:
Hi, Rafael

From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx]
Sent: Friday, February 06, 2015 9:27 AM

On Friday, February 06, 2015 08:57:37 AM Lv Zheng wrote:
This patchset contains 3 cleanups related to the EC driver:
1. Command flushing (command grace period)
This patchset flushes EC commands before suspending/resuming, so that
there won't be timeout for the incomplete commands after resuming.
2. Query flushing (query grace period)
This patchset flushes EC event queries before suspending/resuming, so
that there won't be broken events remained in the firmware queue.
3. Command storming prevention
This patchset corrects command storming prevention logic because of
the GPE raw handler mode.
The request reference count debugging messages can be used to detect broken
EC transactions. It should always drop to 1 when the driver is idle during
the runtime.

Note that after flushing before suspending, EC GPE is still enabled to keep
the old behavior.

Lv Zheng (5):
ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.
ACPI/EC: Add command flushing support.
ACPI/EC: Refine command storm prevention support.
ACPI/EC: Add query flushing support.
ACPI/EC: Add GPE reference counting debugging messages.

drivers/acpi/ec.c | 295 ++++++++++++++++++++++++++++++++++++++++-------
drivers/acpi/internal.h | 1 +
2 files changed, 254 insertions(+), 42 deletions(-)
So this is on top of the EC patches you sent previously, right?
Yes.

The sequence is:
ACPICA 20150204 release: http://www.spinics.net/lists/linux-acpi/msg55623.html
ACPI EC GPE race fixes: http://www.spinics.net/lists/linux-acpi/msg55633.html
And this series.

Unfortunately, patch [4/5] from this series broke system suspend on Acer Aspire S5 for me.

Apparently, the box hangs hard during the last stage of suspend (after offlining nonboot CPUs).

The issue is 100% reproducible and reverting the patch (along with [5/5] that depends on it) fixes the problem, so I'm going to push the reverts to Linus on Friday.

I can send you an acpidump output from the affected machine, but I won't be able to do any testing on it before Feb 23, so reverting is the only viable option for the time being.

Please let me know if you want the acpidump output.

Kind regards,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/