23 Jul, 2014

2 commits

  • GHES currently maps two pages with atomic_ioremap. From now
    on, NMI is architectural depended so there is no need to allocate
    an NMI page for platforms without NMI support.

    To make it possible to not use a second page, swap the existing
    page order so that the IRQ context page is first, and the optional
    NMI context page is second. Then, use HAVE_ACPI_APEI_NMI to decide
    how many pages are to be allocated.

    Signed-off-by: Tomasz Nowicki
    Acked-by: Borislav Petkov
    Signed-off-by: Tony Luck

    Tomasz Nowicki
     
  • This commit abstracts MCE calls and provides weak corresponding default
    implementation for those architectures which do not need arch specific
    actions. Each platform willing to do additional architectural actions
    should provides desired function definition. It allows us to avoid wrap
    code into #ifdef in generic code and prevent new platform from introducing
    dummy stub function too.

    Initially, there are two APEI arch-specific calls:
    - arch_apei_enable_cmcff()
    - arch_apei_report_mem_error()
    Both interact with MCE driver for X86 architecture.

    Signed-off-by: Tomasz Nowicki
    Acked-by: Borislav Petkov
    Signed-off-by: Tony Luck

    Tomasz Nowicki
     

13 Jan, 2012

1 commit


03 Aug, 2011

1 commit

  • as GHES is optional...

    When # CONFIG_ACPI_APEI_GHES is not set:

    (.init.text+0x4c22): undefined reference to `ghes_disable'

    Reported-by: Randy Dunlap
    Acked-by: Randy Dunlap
    Signed-off-by: Len Brown

    Len Brown
     

14 Jul, 2011

1 commit


22 Mar, 2011

1 commit

  • APEI ERST firmware interface and implementation has no multiple users
    in mind. For example, if there is four records in storage with ID: 1,
    2, 3 and 4, if two ERST readers enumerate the records via
    GET_NEXT_RECORD_ID as follow,

    reader 1 reader 2
    1
    2
    3
    4
    -1
    -1

    where -1 signals there is no more record ID.

    Reader 1 has no chance to check record 2 and 4, while reader 2 has no
    chance to check record 1 and 3. And any other GET_NEXT_RECORD_ID will
    return -1, that is, other readers will has no chance to check any
    record even they are not cleared by anyone.

    This makes raw GET_NEXT_RECORD_ID not suitable for used by multiple
    users.

    To solve the issue, an in-memory ERST record ID cache is designed and
    implemented. When enumerating record ID, the ID returned by
    GET_NEXT_RECORD_ID is added into cache in addition to be returned to
    caller. So other readers can check the cache to get all record ID
    available.

    Signed-off-by: Huang Ying
    Reviewed-by: Andi Kleen
    Signed-off-by: Len Brown

    Huang Ying
     

15 Jan, 2011

1 commit

  • Move the evaluation of acpi_pci_osc_control_set() (to request control of
    PCI Express native features) into acpi_pci_root_add() to avoid calling
    it many times for the same root complex with the same arguments.
    Additionally, check if all of the requisite _OSC support bits are set
    before calling acpi_pci_osc_control_set() for a given root complex.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=20232
    Reported-by: Ozan Caglayan
    Tested-by: Ozan Caglayan
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Jesse Barnes

    Rafael J. Wysocki
     

20 May, 2010

2 commits

  • ERST is a way provided by APEI to save and retrieve hardware error
    record to and from some simple persistent storage (such as flash).

    The Linux kernel support implementation is quite simple and workable
    in NMI context. So it can be used to save hardware error record into
    flash in hardware error exception or NMI handler, where other more
    complex persistent storage such as disk is not usable. After saving
    hardware error records via ERST in hardware error exception or NMI
    handler, the error records can be retrieved and logged into disk or
    network after a clean reboot.

    For more information about ERST, please refer to ACPI Specification
    version 4.0, section 17.4.

    This patch incorporate fixes from Jin Dongming.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    CC: Jin Dongming
    Signed-off-by: Len Brown

    Huang Ying
     
  • HEST describes error sources in detail; communicating operational
    parameters (i.e. severity levels, masking bits, and threshold values)
    to OS as necessary. It also allows the platform to report error
    sources for which OS would typically not implement support (for
    example, chipset-specific error registers).

    HEST information may be needed by other subsystems. For example, HEST
    PCIE AER error source information describes whether a PCIE root port
    works in "firmware first" mode, this is needed by general PCIE AER
    error subsystem. So a public HEST tabling parsing interface is
    provided.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Huang Ying