Bug 16028 - Failed to receive control of PCIe PME service: ACPI _OSC failed
Summary: Failed to receive control of PCIe PME service: ACPI _OSC failed
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
: 17792 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-22 12:49 UTC by Atanas Zhelev
Modified: 2010-09-29 02:10 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.34
Tree: Mainline
Regression: No


Attachments
lspci -vv output (17.99 KB, text/plain)
2010-05-22 12:49 UTC, Atanas Zhelev
Details
dmesg output (47.02 KB, text/plain)
2010-05-22 12:50 UTC, Atanas Zhelev
Details
dmidecode output (14.12 KB, text/plain)
2010-05-22 12:50 UTC, Atanas Zhelev
Details
acpidump output (215.26 KB, text/plain)
2010-05-22 12:51 UTC, Atanas Zhelev
Details
custom dsdt (401.61 KB, application/octet-stream)
2010-06-07 07:14 UTC, Zhang Rui
Details
dmesg with custom DSDT (46.01 KB, text/x-log)
2010-06-10 17:07 UTC, Atanas Zhelev
Details
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff (495.21 KB, text/x-log)
2010-06-11 15:19 UTC, Atanas Zhelev
Details
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M (641.32 KB, text/x-log)
2010-06-12 11:29 UTC, Atanas Zhelev
Details
dmesg with acpi.debug_level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M (46.64 KB, text/x-log)
2010-06-14 08:46 UTC, Atanas Zhelev
Details
custom DSDT (401.75 KB, application/octet-stream)
2010-06-17 03:14 UTC, Zhang Rui
Details
dmesg kernel 2.6.33 (38.91 KB, text/x-log)
2010-06-20 15:46 UTC, Atanas Zhelev
Details
dmesg kernel 2.6.34 (47.78 KB, text/x-log)
2010-06-20 15:46 UTC, Atanas Zhelev
Details

Description Atanas Zhelev 2010-05-22 12:49:07 UTC
Hello,

Latest working kernel version: 2.6.33.4
Earliest failing kernel version: 2.6.34
Distribution: ArchLinux x86_64, kernel is from distro repository but only has 2 patches for aufs2
Hardware Environment: dell studio xps 1647


Problem Description:
When booting the latest kernel i see those error messages in dmesg. Kernel 2.6.33.x does not show such problem.

pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
pcieport 0000:00:1c.1: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:1c.1: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13
pcieport 0000:00:1c.3: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:1c.3: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:1c.3:pcie01 failed with error -13
pcieport 0000:00:1c.4: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:1c.4: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:1c.4:pcie01 failed with error -13
pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 0 1f 
pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: ACPI _OSC failed
pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13

Steps to reproduce:
boot, check dmesg
Comment 1 Atanas Zhelev 2010-05-22 12:49:53 UTC
Created attachment 26497 [details]
lspci -vv output
Comment 2 Atanas Zhelev 2010-05-22 12:50:22 UTC
Created attachment 26498 [details]
dmesg output
Comment 3 Atanas Zhelev 2010-05-22 12:50:48 UTC
Created attachment 26499 [details]
dmidecode output
Comment 4 Atanas Zhelev 2010-05-22 12:51:10 UTC
Created attachment 26500 [details]
acpidump output
Comment 5 Atanas Zhelev 2010-05-22 13:01:57 UTC
Hello,

i forgot to mention that this error doesn't seem to cause any harm/problems on the machine whatsoever.

--
BRS
Atanas Zhelev
Comment 6 Zhang Rui 2010-06-07 07:14:45 UTC
Created attachment 26678 [details]
custom dsdt

please set CONFIG_ACPI_DEBUG, apply the custom dsdt,
and then boot the new kernel with boot option acpi.debug_level=0x02 acpi.debug_layer=0xffffffff.

please attach the dmesg output after boot with the custom DSDT.
Comment 7 Atanas Zhelev 2010-06-10 17:06:37 UTC
Hi,

attaching the dmesg output with the custom DSDT

--
BRS
Atanas Zhelev
Comment 8 Atanas Zhelev 2010-06-10 17:07:13 UTC
Created attachment 26713 [details]
dmesg with custom DSDT
Comment 9 Zhang Rui 2010-06-11 01:26:42 UTC
please reboot with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff this time, and attach the dmesg output.
Comment 10 Atanas Zhelev 2010-06-11 15:19:15 UTC
Created attachment 26727 [details]
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff

Attaching the requested log
Comment 11 Zhang Rui 2010-06-12 06:44:12 UTC
oops, too much debug output this time, please add boot option log_buf_len=1M this time so that we can catch more logs.
Comment 12 Atanas Zhelev 2010-06-12 11:29:01 UTC
Created attachment 26740 [details]
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M

done
Comment 13 Zhang Rui 2010-06-13 02:56:24 UTC
(In reply to comment #9)
> please reboot with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff this
> time, and attach the dmesg output.

Oops, I must be sleepy when writing this.
please boot with acpi.debug_level=0x2002 instead of acpi.debug.level=0x2002.
I promise this is the last time you need to reboot your machine for this test. :p
Comment 14 Atanas Zhelev 2010-06-14 08:46:19 UTC
Created attachment 26759 [details]
dmesg with acpi.debug_level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M

Don't worry about it. Log attached.
Comment 15 Zhang Rui 2010-06-17 03:13:01 UTC
well, it seems that a flag in firmware is cleared, result in the failed _OSC evaluation.
But this can not explain why this is a regression...

Atanas, please apply the custom dsdt I attached below, on both 2.6.33 and 2.6.34, and attach the dmesg output  with acpi.debug_level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M
Comment 16 Zhang Rui 2010-06-17 03:14:19 UTC
Created attachment 26822 [details]
custom DSDT
Comment 17 Atanas Zhelev 2010-06-20 15:46:31 UTC
Created attachment 26868 [details]
dmesg kernel 2.6.33
Comment 18 Atanas Zhelev 2010-06-20 15:46:58 UTC
Created attachment 26869 [details]
dmesg kernel 2.6.34
Comment 19 Atanas Zhelev 2010-06-20 15:48:11 UTC
Hi,

sorry for the late reply, time is scarce lately.
Anyway, logs are attached.

--
BRS
Atanas Zhelev
Comment 20 Zhang Rui 2010-06-21 03:17:44 UTC
Right, the warning message is introduced by commit c7f486567c1d0acd2e4166c47069835b9f75e77b, which is harmless IMO.

Actually, every evaluation of _OSC will fail on this machine.

Here is a piece of the AML code of _OSC method:

                If (LAnd (LEqual (Arg0, GUID), NEXP))
                {
                   ...
                }
                Else
                {
                   GUID not match
                }
and the NEXP bit is cleared...

I'm not sure what MEXP stands for and why it is cleared.

Bob, we have a similar internal bug report, right?
Comment 21 Rafael J. Wysocki 2010-06-21 18:07:37 UTC
The warning should go away after this patch:

https://patchwork.kernel.org/patch/106865/

has been applied.
Comment 22 Zhang Rui 2010-06-23 03:01:03 UTC
Right.

Bug closed.
Comment 23 Zhang Rui 2010-09-14 01:35:03 UTC
*** Bug 17792 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.