https://bugzilla.kernel.org/show_bug.cgi?id=90351

            Bug ID: 90351
           Summary: \_SB_.PCI0:_OSC invalid UUID on Samsung NP530U3C  _OSC
                    request data:1 1f 0
           Product: ACPI
           Version: 2.5
    Kernel Version: 3.14
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: BIOS
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

On dmesg I see 

[    0.152457] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    0.152466] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM
S
egments MSI]
[    0.152613] \_SB_.PCI0:_OSC invalid UUID
[    0.152614] _OSC request data:1 1f 0 
[    0.152619] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM


which is very similar to #36932 however the explanation in that case was as a
BIOS bug in https://bugzilla.kernel.org/show_bug.cgi?id=36932#c26 given by the
fact that certain variable (NEXP) was not initialized in any of the DSDT/SSDT.

In this case the implementation of _OSC in DSDT is similar to #36932 (with an
extra check) but the variable NEXP is declared in 


  OperationRegion (GNVS, SystemMemory, 0xDAF7CE18, 0x01C8)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
....
     Offset (0xE1), 
        OSCC,   8, 
        NEXP,   8, 
        SBV1,   8, 
....


And that region of memory is reported as ACPI NVS

[    0.000000] BIOS-e820: [mem 0x00000000bd4b5000-0x00000000ce3eefff] usable
[    0.000000] BIOS-e820: [mem 0x00000000ce3ef000-0x00000000daeeefff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000daeef000-0x00000000daf9efff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000daf9f000-0x00000000daffefff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000dafff000-0x00000000daffffff] usable

So it does not get overwritten by the OS on boot. I don't know anything about
ACPI and just started reading today, but from the ACPI specification the _OSC
parameters are a UUID in Arg0, a Revision ID in Arg1 and a paramenter count in
Arg2 so the line in dmesg:

[    0.152614] _OSC request data:1 1f 0 

I see as if the kernel is passing 0 parameters in Arg3. 

The first check in the definition of _OSC in DSDT that may be the cause of this
is:

 Method (_OSC, 4, Serialized)  // _OSC: Operating System Capabilities
            {
                Store (Arg3, Local0)
                CreateDWordField (Local0, Zero, CDW1)
                CreateDWordField (Local0, 0x04, CDW2)
                CreateDWordField (Local0, 0x08, CDW3)
                If (^XHC.CUID (Arg0))
                {
                    Return (^XHC.POSC (Arg1, Arg2, Arg3))
                }
                Else
                {
                    If (_OSI ("Windows 2012"))
                    {
                        If (LEqual (XCNT, Zero))
                        {
                            ^XHC.XSEL ()
                            Increment (XCNT)
                        }
                    }
                }

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to