Created attachment 216971 [details]
We faced with acpi problem in our Supermicro SYS-5027R-WRF server, motherboard X9SRW-F. We have latest BIOS version 3.2a from Supermicro. We tested Debian 8 and CentOS 7 distros with default kernels. This problem doesn't appear in old 2.6 kernels with CentOS 6 for example. We also tried Debian's 4.x kernel and this problem still exists. Is it critical problem? Or we can just use 3.16 kernels and ignore this messages and disable these events?
Here are these two errors:
[ 0.410480] ACPI Error: [\_SB_.PRAD] Namespace lookup failure, AE_NOT_FOUND (20130517/psargs-359)
[ 0.410483] ACPI Error: Method parse/execution failed [\_GPE._L24] (Node ffff880853ca18c0), AE_NOT_FOUND (20130517/psparse-536)
[ 0.410487] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L24] (20130517/evgpe-579)
please attach the acpidump output.
Created attachment 217101 [details]
These warning messages are not important to me.
The root cause is that, BIOS provides an ACPI table named PRAD, which provides the ACPI processor aggregator device.
But unfortunately, this table can not be recognized properly because the table has an invalid signature, aka, PRAD.
This problem actually exists on all kernel versions, because ACPI never supports a "PRAD" table.
I will close this bug as this is a firmware issue to me, and it's safe for you to use any kernel versions with the error messages. Maybe Lv can explain why these error messages do not exist in earlier kernels.
Thanks for help!
Last question. Does this [\_GPE._L24] also relate to this problem with PRAD table and we can ignore it?
I'll re-open this bug.
Looks like a bug in ACPICA.
When AML code specifies a table signature, what's the benefit of AML interpreter to disallow tables named with such signature to be loaded?
And such bugs are not isolated.
We can see several similar issues.
I suppose this issue can be fixed by this pull request:
And this commit:
Tables: Do not validate signature for dynamic table load …
lv, if this is an ACPICA bug, please file a ACPICA bug report to track the problem there. thanks!
OK, linking this bug to this ACPICA bug link:
Patch upstreamed to ACPICA, will appear in Linux upstream soon.