Bug 16028
| Summary: | Failed to receive control of PCIe PME service: ACPI _OSC failed | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Atanas Zhelev (zmeyski) |
| Component: | Other | Assignee: | Zhang Rui (rui.zhang) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, caravena, lenb, rjw, Robert.Moore |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.34 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
lspci -vv output
dmesg output dmidecode output acpidump output custom dsdt dmesg with custom DSDT dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M dmesg with acpi.debug_level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M custom DSDT dmesg kernel 2.6.33 dmesg kernel 2.6.34 |
||
|
Description
Atanas Zhelev
2010-05-22 12:49:07 UTC
Created attachment 26497 [details]
lspci -vv output
Created attachment 26498 [details]
dmesg output
Created attachment 26499 [details]
dmidecode output
Created attachment 26500 [details]
acpidump output
Hello, i forgot to mention that this error doesn't seem to cause any harm/problems on the machine whatsoever. -- BRS Atanas Zhelev 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.
Hi, attaching the dmesg output with the custom DSDT -- BRS Atanas Zhelev Created attachment 26713 [details]
dmesg with custom DSDT
please reboot with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff this time, and attach the dmesg output. Created attachment 26727 [details]
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff
Attaching the requested log
oops, too much debug output this time, please add boot option log_buf_len=1M this time so that we can catch more logs. Created attachment 26740 [details]
dmesg with acpi.debug.level=0x2002 acpi.debug_layer=0xffffffff log_buf_len=1M
done
(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 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.
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 Created attachment 26822 [details]
custom DSDT
Created attachment 26868 [details]
dmesg kernel 2.6.33
Created attachment 26869 [details]
dmesg kernel 2.6.34
Hi, sorry for the late reply, time is scarce lately. Anyway, logs are attached. -- BRS Atanas Zhelev 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?
The warning should go away after this patch: https://patchwork.kernel.org/patch/106865/ has been applied. Right. Bug closed. *** Bug 17792 has been marked as a duplicate of this bug. *** |