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

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 ?

(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.

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.

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...

(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.

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...

(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.

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?

> 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.

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.