Bug 851760 - ACPI errors on HP workstation
ACPI errors on HP workstation
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.3
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Tony Camuso
Jeff Bastian
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-25 07:03 EDT by o.h.weiergraeber
Modified: 2013-12-05 12:32 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-05 12:32:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages from EL 6.3 containing ACPI errors (262.77 KB, application/x-troff-man)
2012-08-25 07:03 EDT, o.h.weiergraeber
no flags Details

  None (edit)
Description o.h.weiergraeber 2012-08-25 07:03:55 EDT
Created attachment 606989 [details]
/var/log/messages from EL 6.3 containing ACPI errors

Description of problem:
During botup on my HP xw8600 workstation, the EL6 kernel logs this warning several times:

ACPI Error (dsfield-0143): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff88022ad526c8), AE_ALREADY_EXISTS
ACPI: Marking method _OSC as Serialized because of AE_ALREADY_EXISTS error

In contrast, EL5 boots without such errors on the same system.
Note that this bug had already been reported for FC12 (BUG 600364), but has never been addressed since FC12 was no longer supported. But since EL6 is related to FC12, it seems the error has in fact persisted.

I have attached the /var/log/messages file from the affected EL 6.3 system.

Version-Release number of selected component (if applicable):
kernel-2.6.32-279.5.2.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install EL6 on affected system
2. Observe errors in /var/log/messages
  
Actual results:
ACPI kernel errors as described above

Expected results:
No ACPI errors

Additional info:
Comment 2 Matthew Garrett 2012-10-24 12:04:40 EDT
HP's firmware doesn't like _OSC being called multiple times. This is a violation of 6.2.10 of the ACPI specification, but was worked around in upstream commit 415e12b2379239973feab91850b0dce985c6058a
Comment 3 o.h.weiergraeber 2012-10-28 16:25:56 EDT
Thanks for your reply, Matthew.
As far as I can see, the commit you mentioned dates from Jan 2011.
Is there a chance to get this workaround in RHEL 6 ?
Comment 5 Tony Camuso 2012-11-05 16:05:57 EST
(In reply to comment #3)

Can you send us the output of the following command?

dmidecode | grep -e Date -e Vendor -e Version -e Product | head -n 4

Thanks.
Comment 6 o.h.weiergraeber 2012-11-06 13:43:50 EST
OK, this is the information requested:

 	Vendor: Hewlett-Packard
	Version: 786F5 v01.46
	Release Date: 09/20/2012
	Product Name: HP xw8600 Workstation

The BIOS is the very latest available for this machine.
Comment 7 o.h.weiergraeber 2012-12-21 14:58:37 EST
Any news on this issue?
For an administrator, it would be important to know if this message indicates a real problem (which might cause instability or other problems), or should rather be taken as a piece of information without further implications.

Notably, as indicated in the original report, the message does not appear under EL5.x; it is true that the official HCL does not list EL6 for this machine (nor for any xw series workstation), but I thought this was merely because those machines were no longer sold at the time EL6 was launched, so nobody felt a need to certify them...
Comment 8 Tony Camuso 2013-01-10 08:00:38 EST
(In reply to comment #7)
> Any news on this issue?
> For an administrator, it would be important to know if this message
> indicates a real problem (which might cause instability or other problems),
> or should rather be taken as a piece of information without further
> implications.

It is unlikely that you have experienced any instability due to this error. It is related to power management.

> Notably, as indicated in the original report, the message does not appear
> under EL5.x; it is true that the official HCL does not list EL6 for this
> machine (nor for any xw series workstation), but I thought this was merely
> because those machines were no longer sold at the time EL6 was launched, so
> nobody felt a need to certify them...

According to our certs list, this system is only certified to run RHEL4.5+ and RHEL5. 

If the system is not certified to run RHEL6, then such a configuration is not supported. 

However, we will try to fix it if we discover that the problem is due to a dormant kernel bug. 

The upstream workaround commit 415e12b2 that Matthew mentioned was backported into RHEL6.3, so this may be a different problem.
Comment 9 o.h.weiergraeber 2013-01-13 03:19:42 EST
Thanks a lot for your comments.

As to the cert list, are you implying that the machine has not been certified *because* of this acpi problem? Or was it just because HP never marketed it with EL6 and was just not interested in a certification?

Anyway, degradation of hardware support with a new version of an OS is not what one would normaly expect, at least with a fairly recent piece of hardware. On the other hand, maybe HP is to blame for deviating from acpi standards...
Comment 10 Tony Camuso 2013-01-13 07:41:32 EST
(In reply to comment #9)

> As to the cert list, are you implying that the machine has not been
> certified *because* of this acpi problem? Or was it just because HP never
> marketed it with EL6 and was just not interested in a certification?

HP is not the only vendor that limits hardware support to fixed OS releases. 

> Anyway, degradation of hardware support with a new version of an OS is not
> what one would normaly expect, at least with a fairly recent piece of
> hardware. On the other hand, maybe HP is to blame for deviating from acpi
> standards...

I don't think you can say that hardware support has been degraded. If you ask HP or RH for assistance with RHEL4.5+ or RHEL5+ on that system, the support is there. 

The xw8600 was shipped in May 2009. RHEL6 was released in November of 2010.

At the time the xw8600 BIOS was developed (2008-2009), ACPI was at v3. I'm reasonably certain that the BIOS in your system is compliant with ACPI v3. ACPI v4 introduced a lot of changes, and a new BIOS development effort would be required to comply with it. RHEL6 uses ACPI v4. That is probably why the system does not officially support RHEL6.  

All that being said, however, I will try to determine why the upstream workaround applied to RHEL6 does not work as expected. Please give me some time, though. 

Meanwhile, I think you can safely continue to use the system with RHEL6 and ignore the ACPI errors. The only effect I can surmise is that the system's power regulation remains under control of the HP BIOS, which is not a bad thing. It is unlikely that your system's performance is adversely affected.

xw8600 is not the only platform and RHEL6 is not the only OS exhibiting the problem. If you want to read more about it, google _OSC AE_NOT_FOUND.
Comment 11 o.h.weiergraeber 2013-01-17 12:05:22 EST
Thank you very much for the thorough explanation.

Looking for the actual ACPI version implemented in this machine, I found this document

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=115&prodSeriesId=3432827&prodTypeId=12454&objectID=c01316837

As for the BIOS ROM, it states:

"Advanced Configuration and Power Management Interface, Version 2.0"

Was the workaround meant to also consider hardware with ACPI v2? If not, could it be modified to do so?
Comment 12 Tony Camuso 2013-01-17 12:17:42 EST
> Was the workaround meant to also consider hardware with ACPI v2? If not, could 
> it be modified to do so?

Good question. I'll try to have a look at it over the next few weeks.
Comment 13 Tony Camuso 2013-12-05 12:32:38 EST
Well, it's been more than a few weeks. 

ACPI 2.0 specification does not support the _OSC object, so the MJG's kernel workaround would not help.

I am closing this bug as NOTABUG, since the vendor did not intend the power management of this system to be under OS control.

If you believe this is in error, you are free to reopen the bug.

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