Bug 36932

Created attachment 61202 [details]
lspci -vvnn

Created attachment 61522 [details]
dmidecode_VGN-NS130FE.log

please attach the output from acpidump

was this message present in earlier kernels, such as 2.6.38
or 2.6.39?

Created attachment 62002 [details]
acpidump_VGN-NS130FE.log

(In reply to comment #3)

[...]


> was this message present in earlier kernels, such as 2.6.38
> or 2.6.39?

No message "pci0000:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d" in kernel's =< 2.6.39

Created attachment 62022 [details]
dmesg 3.0-rc3

Created attachment 62032 [details]
dmesg 2.6.39 no mesge: "pci0000:00: ACPI _OSC request failed (AE_ERROR) ..."

Created attachment 63122 [details]
dmesg 3.0-rc4

I can also confirm this. This happens on Toshiba Laptop Satellite L670-1JN. Using kernel 3.0.0 from debian/unstable.

Grub option:

$ cat /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"
GRUB_CMDLINE_LINUX="acpi=copy_dsdt"

Created attachment 66972 [details]
dmesg for laptop toshiba L670-1JN

Created attachment 68412 [details]
kernel boot messages

I have the same error message on Dell XPS L502X laptop with Gentoo kernel 3.0.1.
At the beginning of the log it complains also that HEST: Table not found.

Created attachment 68422 [details]
acpidump

I see a similar message, and also:

pci_bus 0000:ff: on NUMA node 0
 pci0000:ff: Requesting ACPI _OSC control (0x1d)
 pci0000:ff: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1
d
ACPI _OSC control for PCIe not granted, disabling ASPM

on a dell XPS L501X with Gentoo kernel 3.0

will attach dmesg, acpidump and dmidecode output

Created attachment 70242 [details]
dmesg from L501X

Created attachment 70252 [details]
acpidump output from L501X

Created attachment 70262 [details]
dmidecode output from L501X

It's great that the kernel bugzilla is back.

Can you please verify if the problem still exists in the latest upstream
kernel? If yes, please attach the dmesg output with the error message.

Created attachment 72120 [details]
dmesg output

With 3.2.1 I still see this:

\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 8 1f 

and 

\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 1f 1f 
 pci0000:00: Requesting ACPI _OSC control (0x1d)
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1d 
 pci0000:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d
ACPI _OSC control for PCIe not granted, disabling ASPM

full dmesg attached

Created attachment 72446 [details]
Lenovo G470 aka LENOVO 20078 (laptop)  ; Essential  IdeaPad

http://rzr.online.fr/q/lenovo

I think I have the same problem on a HP Probook 6450b, kernel 3.2.7 :

[    0.745523]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.746989]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.754681]  pci0000:ff: Requesting ACPI _OSC control (0x1d)
[    0.754765]  pci0000:ff: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[    0.754877] ACPI _OSC control for PCIe not granted, disabling ASPM

More details in the bug report for my distro : https://bugs.mageia.org/show_bug.cgi?id=4478 (it didn't change since 3.2.5 kernel)

I get this error as well. And I see no progress on this bug in 2 months...:( My shiny new laptop is unusable on Linux. The battery life is like half of what Windows 7 gives me.

(In reply to comment #21)
> My shiny new laptop is unusable on Linux.

Well, this is a big word : I'd just say on latest Linux kernels, as kernel < 2.6.28 is a good battery life friend here.
May I suggest you at least to try a Linux distro that allows the GRUB pcie_aspm=force workaround? At least Mageia 1 without kernel updates works for me : 10W idle with Windows 7 and Linux.

The Status NEEDINFO should not help making this bug report active, but I cannot change it?

pcie_aspm=force was the first thing I tried.

Same problem also on kernel 3.4.9-gentoo.

The relevant line in dmesg are

[    0.340807]  pci0000:00: Requesting ACPI _OSC control (0x15)
[    0.340814]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x15
[    0.340818] ACPI _OSC control for PCIe not granted, disabling ASPM

I do not know if it is relevant for the problem, but in dmesg appear also the following warning about ACPI:

ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120320/tbfadt-579)

Adding pcie_aspm=force on kernel command line does not solve the problem, since the aspm will be disabled later during the boot (with the message above).

Hi,

This is a BIOS bug.

I tested and made sure that there isn't any Linux ACPI bugs for this issue.

Decompilation result of _OSC implementation:

            Name (GUID, Buffer (0x10)
            {
                /* 0000 */   0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40,
                /* 0008 */   0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66
            })
            Name (SUPP, 0x00)
            Name (CTRL, 0x00)
            Method (_OSC, 4, Serialized)  // _OSC: Operating System Capabilities
            {
                Store (Arg3, Local0)
                CreateDWordField (Local0, 0x00, CDW1)
                CreateDWordField (Local0, 0x04, CDW2)
                CreateDWordField (Local0, 0x08, CDW3)
                If (LAnd (LEqual (Arg0, GUID), NEXP))
>> Test result shows Arg0 equals to GUID, thus the kernel log should be
>> generated by the NEXP value (=0).
                {
                    Store (CDW2, SUPP)
                    Store (CDW3, CTRL)
                    If (Not (And (CDW1, 0x01)))
                    {
                        If (And (CTRL, 0x02))
                        {
                            NHPG ()
                        }

                        If (And (CTRL, 0x04))
                        {
                            NPME ()
                        }
                    }

                    If (LNotEqual (Arg1, One))
                    {
                        Or (CDW1, 0x08, CDW1)
                    }

                    If (LNotEqual (CDW3, CTRL))
                    {
                        Or (CDW1, 0x10, CDW1)
                    }

                    Store (CTRL, CDW3)
                    Store (CTRL, OSCC)
                    Return (Local0)
                }
                Else
                {
                    Or (CDW1, 0x04, CDW1)
>> This causes GUID mismatch error reported by ACPICA.
                    Return (Local0)
                }
            }

The problem is the NEXP variable which has never been initialized in any of the DSDT/SSDT codes.
    OperationRegion (GNVS, SystemMemory, 0xB7B0AD90, 0x0100)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        ..., 
        Offset (0xE1), 
        OSCC,   8, 
        NEXP,   8, 
>> NEXP is defined inside an 256 bytes system memory region locating at
>> 0xB7B0AD90.  NEXP's address offset is 0xE2.
        ...
    }

I don't know what this region is for.
It might be something like a BIOS/Firmware reserved or the region is controlled by some Windows vendor drivers.  I cannot find any clue from the namespace codes, there isn't any users in the ACPI namespace.

According to the e820 map from your machine, this region is reported by BIOS as usable, thus Linux will use it by initializing it to ZEROs.
 ...
 BIOS-e820: 0000000000100000 - 00000000bba7c000 (usable)
>> This belongs to a usable region.
 ...

The e820 map is reported by the BIOS, thus the issue is caused by your BIOS or there is a vendor driver gap for this issue.

This is confirmed as a known BIOS issue and thus will be closed without fix.
Thanks for reporting.

*** Bug 90351 has been marked as a duplicate of this bug. ***