5

I am not sure what does this following means:-

[    0.652039] ACPI: Added _OSI(Module Device)
[    0.652044] ACPI: Added _OSI(Processor Device)
[    0.652049] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.652054] ACPI: Added _OSI(Processor Aggregator Device)
[    0.656286] ACPI: EC: Look up EC in DSDT
[    0.660361] ACPI: Executed 1 blocks of module-level executable AML code
**[    0.720310] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored**
[    0.721539] ACPI: SSDT 000000009ce70798 00727 (v01  PmRef  Cpu0Cst 00003001 INTL 20100121)
[    0.722623] ACPI: Dynamic OEM Table Load:
[    0.722630] ACPI: SSDT           (null) 00727 (v01  PmRef  Cpu0Cst 00003001 INTL 20100121)
[    0.752832] ACPI: SSDT 000000009ce71a98 00303 (v01  PmRef    ApIst 00003000 INTL 20100121)

What kind of bug is this? Does this bug affects my system performance.

1
  • 3
    This is nothing to worry about. The firmware says it supports _OSI(Linux) and the kernel ignores this and defaults to pretending to be the latest version of Windows to try and ensure Linux ACPI behaves like Windows does. Aug 14, 2012 at 16:39

3 Answers 3

9

For what I can understand it means that a query from the Bios/Firmware related to the ACPI (If you are running a laptop it means the battery, if you are running a Desktop PC it means a UPS or similar) is not recognized.

What Ubuntu did there was ignore the query to not cause problems. Some of the stuff you might see because of this are:

  1. Ubuntu battery state does not detect when the battery has been disconnected. Showing you still the same "Battery Connected" symbol.

  2. Battery charging notification is not updated correctly.

This does not mean the battery will not charge correctly, or that it did not detect the state of the battery correctly, it just means that in the Desktop you will not see it correctly. This does not even mean it will not show correctly to you.

For performance related stuff, you will not suffer any performance problems. It will be running the same as always.

Basically this comes from a BIOS, first assuming that the OS is Windows and then doing a query to it to confirm some information.

Anyway don't worry about it, Ubuntu and any other Linux distro can effectively just tell the BIOS that it is in fact Windows and get the correct query from it. Dmesg and the booting system just post that message there to notify you about the BIOS asking something to the OS (Remember, it is assuming is Windows) and Linux trying to fake it so the BIOS sends the complete query. This is a reason why BIOS manufacturers should not assume that the only hardware they will work on is Windows.

1
  • It's not specific to power or performance. _OSI was meant to provide a means for the firmware to ask the OS if it is compatible with an ACPI interface. But was misused to identify the OS, which is why _OSI(Linux) is a BUG. kernel.org/doc/Documentation/acpi/osi.txt
    – Lucas
    Apr 13, 2018 at 11:37
9

The ACPI tables (DSDT, SSDT) are provided by the BIOS. These ACPI tables allows the OS the control the hardware through an abstraction layer (ACPI). Manufacturers can use the ACPI _OSI method (Operating System Interfaces) to query the OS for certain capabilities.

Through this mechanism, ACPI can detect the OS (and version) and apply some quirks if necessary. This is especially useful for Windows machines as newer features of a machine may not be supported by older Windows versions. However, in Linux, the philosophy is that if a feature is not supported by the Linux kernel, exclusions should not be made by the BIOS manufacturer. Instead, the community (kernel developers) have to add code to support those features from newer machines.

In the past, some BIOS manufacturers removed features if they detect a Linux system. While a feature may not be supported at the time of the BIOS release, in the future, it could. Because of that, queries for "Linux" are ignored.

0

There's a table in the BIOS being queried and some BIOS programmers have used it to do things they shouldn't - to the point where it affected some distros badly. The solution the kernel writers decided to use is to just return FALSE when queried, to stop that noise.

Supposedly if you add acpi_osi=Linux to your kernel command it may fix it, but I didn't find it to work for me on my Asus H81T.

So basically, ignore it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .