Comment 18 for bug 1468180

the failure,
 klog: HIGH Kernel message: [ 0.352459] \_SB_:_OSC invalid UUID

From the Acpi table,
    Method (WOSC, 4, NotSerialized)
    {
        CreateDWordField (Arg3, Zero, CDW1)
        If (LEqual (Arg0, Buffer (0x10)
                {
                    /* 0000 */ 0x0C, 0x5E, 0x85, 0xED, 0x90, 0x6C, 0xBF, 0x47,
                    /* 0008 */ 0xA6, 0x2A, 0x26, 0xDE, 0x0F, 0xC5, 0xAD, 0x5C
                }))
        {
            CreateDWordField (Arg3, 0x04, CDW2)
            CreateDWordField (Arg3, 0x08, CDW3)
            If (WHEA)
            {
                If (And (CDW2, One))
                {
                    Return (One)
                }
            }
        }
        Else
        {
            Or (CDW1, 0x04, CDW1)
        }

        Return (Zero)
    }

    Method (_SB._OSC, 4, NotSerialized) // _OSC: Operating System Capabilities
    {
        If (WOSC (Arg0, Arg1, Arg3, Arg3))
        {
            Return (Arg3)
        }

        Return (Arg3)
    }

Seems that firmware only support to report the APEI status, by the Microsoft WHEA defined UUID "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c"
Kernel expects the _OSC method following the ACPI spec Platform-Wide OSPM Capabilities UUID(0811B06E-4A27-44F9-8D60-3CBBC22E7B48)
So, when the kernel driver, function acpi_bus_osc_support() in drivers/acpi/bus.c , checks the platform-Wide OSPM Capabilities with it's UUID, got the invalid UUID, because firmware ACPI \_SB_:_OSC method checks the Microsoft WHEA defined UUID.

Although, the Microsoft WHEA defined UUID also be handled by the kernel driver, function apei_osc_setup() in acpi/apei/apei-base.c, so it should not have any problems. I still suggest that the firmware implement the Platform-Wide OSPM Capabilities UUID defined on the ACPI spec, because it covers the APEI capabilities define.