Patchwork [8/8] data: klog.json: ACPICA ACPI_ERROR messages, utmutex.c

login
register
mail settings
Submitter Colin King
Date Nov. 20, 2012, 11:28 a.m.
Message ID <1353410884-4438-9-git-send-email-colin.king@canonical.com>
Download mbox | patch
Permalink /patch/200305/
State Accepted
Headers show

Comments

Colin King - Nov. 20, 2012, 11:28 a.m.
From: Colin Ian King <colin.king@canonical.com>

ACPICA ACPI_ERROR messages from utmutex.c

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 data/klog.json |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)
Keng-Yu Lin - Nov. 22, 2012, 6:19 a.m.
On Tue, Nov 20, 2012 at 7:28 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> ACPICA ACPI_ERROR messages from utmutex.c
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>  data/klog.json |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/data/klog.json b/data/klog.json
> index a029b5e..bf4d084 100644
> --- a/data/klog.json
> +++ b/data/klog.json
> @@ -77,6 +77,22 @@
>   "firmware_error_warning_patterns":
>   [
>    {
> +   "compare_mode": "regex",
> +   "log_level": "LOG_LEVEL_HIGH",
> +   "tag": "FWTS_TAG_ACPI",
> +   "pattern": "Mutex .* is not acquired, cannot release",
> +   "advice": "An attempt to release (unlock) an ACPI related mutex has occurred. This mutex could not be released. This is most probably a bug in the AML code where a Release opcode has been executed that does not match up with an earlier corresponding Mutex opcode. It may also be a bug in the ACPI driver, but this is less likely.",
> +   "label": "KlogAcpiMutexReleaseError"
> +  },
> +  {
> +   "compare_mode": "regex",
> +   "log_level": "LOG_LEVEL_HIGH",
> +   "tag": "FWTS_TAG_ACPI",
> +   "pattern": "Thread .* could not acquire Mutex",
> +   "advice": "A mutex could not be acquired (locked) and the ACPI driver has flagged this up as an exception error. If this occurs when executing a AML Mutex opcode there could be race condition errors if the AML is not checking the return from the Mutex operation and a lot of firmware does omit this check.",
> +   "label": "KlogAcpiMutexAcquireError"
> +  },
> +  {
>     "compare_mode": "string",
>     "log_level": "LOG_LEVEL_CRITICAL",
>     "tag": "FWTS_TAG_ACPI",
> --
> 1.7.10.4
>
Acked-by: Keng-Yu Lin <kengyu@canonical.com>
Ivan Hu - Nov. 23, 2012, 9:56 a.m.
On 11/20/2012 07:28 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> ACPICA ACPI_ERROR messages from utmutex.c
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>   data/klog.json |   16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
>
> diff --git a/data/klog.json b/data/klog.json
> index a029b5e..bf4d084 100644
> --- a/data/klog.json
> +++ b/data/klog.json
> @@ -77,6 +77,22 @@
>    "firmware_error_warning_patterns":
>    [
>     {
> +   "compare_mode": "regex",
> +   "log_level": "LOG_LEVEL_HIGH",
> +   "tag": "FWTS_TAG_ACPI",
> +   "pattern": "Mutex .* is not acquired, cannot release",
> +   "advice": "An attempt to release (unlock) an ACPI related mutex has occurred. This mutex could not be released. This is most probably a bug in the AML code where a Release opcode has been executed that does not match up with an earlier corresponding Mutex opcode. It may also be a bug in the ACPI driver, but this is less likely.",
> +   "label": "KlogAcpiMutexReleaseError"
> +  },
> +  {
> +   "compare_mode": "regex",
> +   "log_level": "LOG_LEVEL_HIGH",
> +   "tag": "FWTS_TAG_ACPI",
> +   "pattern": "Thread .* could not acquire Mutex",
> +   "advice": "A mutex could not be acquired (locked) and the ACPI driver has flagged this up as an exception error. If this occurs when executing a AML Mutex opcode there could be race condition errors if the AML is not checking the return from the Mutex operation and a lot of firmware does omit this check.",
> +   "label": "KlogAcpiMutexAcquireError"
> +  },
> +  {
>      "compare_mode": "string",
>      "log_level": "LOG_LEVEL_CRITICAL",
>      "tag": "FWTS_TAG_ACPI",
>

Acked-by: Ivan Hu <ivan.hu@canonical.com>

Patch

diff --git a/data/klog.json b/data/klog.json
index a029b5e..bf4d084 100644
--- a/data/klog.json
+++ b/data/klog.json
@@ -77,6 +77,22 @@ 
  "firmware_error_warning_patterns":
  [
   {
+   "compare_mode": "regex",
+   "log_level": "LOG_LEVEL_HIGH",
+   "tag": "FWTS_TAG_ACPI",
+   "pattern": "Mutex .* is not acquired, cannot release",
+   "advice": "An attempt to release (unlock) an ACPI related mutex has occurred. This mutex could not be released. This is most probably a bug in the AML code where a Release opcode has been executed that does not match up with an earlier corresponding Mutex opcode. It may also be a bug in the ACPI driver, but this is less likely.",
+   "label": "KlogAcpiMutexReleaseError"
+  },
+  {
+   "compare_mode": "regex",
+   "log_level": "LOG_LEVEL_HIGH",
+   "tag": "FWTS_TAG_ACPI",
+   "pattern": "Thread .* could not acquire Mutex",
+   "advice": "A mutex could not be acquired (locked) and the ACPI driver has flagged this up as an exception error. If this occurs when executing a AML Mutex opcode there could be race condition errors if the AML is not checking the return from the Mutex operation and a lot of firmware does omit this check.",
+   "label": "KlogAcpiMutexAcquireError"
+  },
+  {
    "compare_mode": "string",
    "log_level": "LOG_LEVEL_CRITICAL",
    "tag": "FWTS_TAG_ACPI",