public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Len Brown <lenb@kernel.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
	Tony Luck <tony.luck@intel.com>,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH 09/17] ACPI, APEI, Add APEI bit support in generic _OSC call
Date: Thu, 14 Jul 2011 10:48:37 -0400	[thread overview]
Message-ID: <20110714144837.GB3080@redhat.com> (raw)
In-Reply-To: <1310534068-30547-10-git-send-email-ying.huang@intel.com>

On Wed, Jul 13, 2011 at 01:14:20PM +0800, Huang Ying wrote:
> In APEI firmware first mode, hardware error is reported by hardware to
> firmware firstly, then firmware reports the error to Linux in a GHES
> error record via POLL/SCI/IRQ/NMI etc.
> 
> This may result in some issues if OS has no full APEI support.  So
> some firmware implementation will work in a back-compatible mode by
> default.  Where firmware will only notify OS in old-fashion, without
> GHES record.  For example, for a fatal hardware error, only NMI is
> signaled, no GHES record.
> 
> To gain full APEI power on these machines, APEI bit in generic _OSC
> call can be specified to tell firmware that Linux has full APEI
> support.  This patch adds the APEI bit support in generic _OSC call.

I have been testing this patch for a couple of weeks with no issues that I
have seen.  Without it (and/or the next one), APEI can't really work.

Tested-and-reviewed-by: Don Zickus <dzickus@redhat.com>

> 
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> Reviewed-by: Andi Kleen <ak@linux.intel.com>
> Reviewed-by: Matthew Garrett <mjg@redhat.com>
> ---
>  drivers/acpi/bus.c   |   16 ++++++++++++++--
>  include/linux/acpi.h |    2 ++
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -39,6 +39,7 @@
>  #include <linux/pci.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/apei.h>
>  #include <linux/dmi.h>
>  #include <linux/suspend.h>
>  
> @@ -519,6 +520,7 @@ out_kfree:
>  }
>  EXPORT_SYMBOL(acpi_run_osc);
>  
> +bool osc_sb_apei_support_acked;
>  static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
>  static void acpi_bus_osc_support(void)
>  {
> @@ -541,11 +543,21 @@ static void acpi_bus_osc_support(void)
>  #if defined(CONFIG_ACPI_PROCESSOR) || defined(CONFIG_ACPI_PROCESSOR_MODULE)
>  	capbuf[OSC_SUPPORT_TYPE] |= OSC_SB_PPC_OST_SUPPORT;
>  #endif
> +
> +#ifdef CONFIG_ACPI_APEI_GHES
> +	if (!ghes_disable)
> +		capbuf[OSC_SUPPORT_TYPE] |= OSC_SB_APEI_SUPPORT;
> +#endif
>  	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
>  		return;
> -	if (ACPI_SUCCESS(acpi_run_osc(handle, &context)))
> +	if (ACPI_SUCCESS(acpi_run_osc(handle, &context))) {
> +		u32 *capbuf_ret = context.ret.pointer;
> +		if (context.ret.length > OSC_SUPPORT_TYPE)
> +			osc_sb_apei_support_acked =
> +				capbuf_ret[OSC_SUPPORT_TYPE] & OSC_SB_APEI_SUPPORT;
>  		kfree(context.ret.pointer);
> -	/* do we need to check the returned cap? Sounds no */
> +	}
> +	/* do we need to check other returned cap? Sounds no */
>  }
>  
>  /* --------------------------------------------------------------------------
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -280,6 +280,8 @@ acpi_status acpi_run_osc(acpi_handle han
>  #define OSC_SB_CPUHP_OST_SUPPORT	8
>  #define OSC_SB_APEI_SUPPORT		16
>  
> +extern bool osc_sb_apei_support_acked;
> +
>  /* PCI defined _OSC bits */
>  /* _OSC DW1 Definition (OS Support Fields) */
>  #define OSC_EXT_PCI_CONFIG_SUPPORT		1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2011-07-14 14:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13  5:14 [PATCH 00/17] ACPI, APEI, Patches for 3.1 Huang Ying
2011-07-13  5:14 ` [PATCH 01/17] ACPI, APEI, HEST, Detect duplicated hardware error source ID Huang Ying
2011-07-14  3:28   ` Len Brown
2011-07-13  5:14 ` [PATCH 02/17] ACPI, APEI, ERST, Prevent erst_dbg from loading if ERST is disabled Huang Ying
2011-07-14  3:30   ` Len Brown
2011-07-13  5:14 ` [PATCH 03/17] ACPI, APEI, ERST, Fix erst-dbg long record reading issue Huang Ying
2011-07-14  3:32   ` Len Brown
2011-07-13  5:14 ` [PATCH 04/17] ACPI, APEI, GHES, Do not ratelimit fatal error printk before panic Huang Ying
2011-07-14  3:33   ` Len Brown
2011-07-13  5:14 ` [PATCH 05/17] ACPI, APEI, Add apei_exec_run_optional Huang Ying
2011-07-13  5:14 ` [PATCH 06/17] ACPI, APEI, Use apei_exec_run_optional in APEI EINJ and ERST Huang Ying
2011-07-13  5:14 ` [PATCH 07/17] ACPI, APEI, GHES, Prevent GHES to be built as module Huang Ying
2011-07-14  3:36   ` Len Brown
2011-07-13  5:14 ` [PATCH 08/17] ACPI, APEI, GHES, Support disable GHES at boot time Huang Ying
2011-07-14 14:47   ` Don Zickus
2011-07-15  0:31     ` Huang Ying
2011-07-15 13:33       ` Don Zickus
2011-07-13  5:14 ` [PATCH 09/17] ACPI, APEI, Add APEI bit support in generic _OSC call Huang Ying
2011-07-14 14:48   ` Don Zickus [this message]
2011-07-13  5:14 ` [PATCH 10/17] ACPI, APEI, Add WHEA _OSC support Huang Ying
2011-07-14 14:50   ` Don Zickus
2011-07-13  5:14 ` [PATCH 11/17] Add Kconfig option ARCH_HAVE_NMI_SAFE_CMPXCHG Huang Ying
2011-07-13  5:14 ` [PATCH 12/17] lib, Add lock-less NULL terminated single list Huang Ying
2011-07-13  5:14 ` [PATCH 13/17] lib, Make gen_pool memory allocator lockless Huang Ying
2011-07-13  5:14 ` [PATCH 14/17] ACPI, APEI, GHES, printk support for recoverable error via NMI Huang Ying
2011-07-13  5:14 ` [PATCH 15/17] ACPI, APEI, GHES, Error records content based throttle Huang Ying
2011-07-13  5:14 ` [PATCH 16/17] HWPoison: add memory_failure_queue() Huang Ying
2011-07-13  5:14 ` [PATCH 17/17] ACPI, APEI, GHES: Add hardware memory error recovery support Huang Ying

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=20110714144837.GB3080@redhat.com \
    --to=dzickus@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@intel.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