Bug 201133

Summary:	ACPI BIOS Error (bug): Failure creating [\_SB.PCI0._OSC.CAPB], AE_ALREADY_EXISTS - Toshiba NB250 Netbook
Product:	ACPI	Reporter:	magiblot
Component:	BIOS	Assignee:	acpi_bios
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	magiblot
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	4.*	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg output with acpi-related messages output of acpidump acpi disassemby

Description magiblot 2018-09-14 17:53:17 UTC

Hello,

My Toshiba NB250 netbook, with a Intel Atom N455 processor suffers from the following ACPI error messages upon boot:

> ACPI BIOS Error (bug): Failure creating [\_SB.PCI0._OSC.CAPB],
> AE_ALREADY_EXISTS (20180531/dsfield-179)
> ACPI Error: Method parse/execution failed \_SB.PCI0._OSC, AE_ALREADY_EXISTS
> (20180531/psparse-516)

The netbook works fine, but there are some side effects. ASPM gets disabled, acpi_backlight works while intel_backlight doesn't, and SpeedStep support isn't recognized. The latter is the most severe issue: when in steady state, the processor doesn't slow down the frequency and gets overheated, to the point the fan can't stop spinning. Not only this is very uncomfortable, but also affects the battery duration.

I don't know to which extent these issues are caused by this ACPI error, but since they seem related, I thought it'd best to start investigating here.

I have already read the following similar bug report:

"[CAPB] Namespace lookup failure, AE_ALREADY_EXISTS - Samsung NF310 Netbook"
https://bugzilla.kernel.org/show_bug.cgi?id=23442

Which continues in the ACPICA bugzilla:
https://bugs.acpica.org/show_bug.cgi?id=946

And gets to this conclusion:

> ACPICA behavior is correct in this case as it:
> 1) Follows the ACPI specification
> 2) Behaves exactly the same as Windows

Still, I decided to submit a new bug report because the manufacturer is different (Toshiba instead of Samsung) and because the resolution above doesn't change the fact that ASPM gets disabled: will everything work just as fine if I then force ASPM?

I will be enclosing the output of acpidump and other information.

Thank you very much.

Comment 1 magiblot 2018-09-14 17:55:26 UTC

Created attachment 278541 [details]
dmesg output with acpi-related messages

Comment 2 magiblot 2018-09-14 17:56:39 UTC

Created attachment 278543 [details]
output of acpidump

Comment 3 magiblot 2018-09-14 17:57:43 UTC

Created attachment 278545 [details]
acpi disassemby

Comment 4 magiblot 2018-09-19 20:41:00 UTC

I have found the root cause of the overheating issue, which is the actual issue I wanted to solve, and it has nothing to do with the ACPI error shown at boot.

For the interested, the culprit is the intel_idle driver. Disabling it with the kernel parameter 'intel_idle.max_cstate=0' (so that acpi_idle will be used) makes the processor behave the same as in Linux.

Comment 5 magiblot 2018-09-19 20:47:13 UTC

In addition, the code which produces the ACPI error message is essentially identical to the one from https://bugzilla.kernel.org/show_bug.cgi?id=23442, so this report can be considered a duplicate.

From attachment 278545 [details]:
> Method (_OSC, 4, NotSerialized)  // _OSC: Operating System Capabilities
>     {
>         Local0 = Arg2
>         Local1 = (Local0 * 0x04)
>         Name (BUF1, Buffer (Local1){})
>         BUF1 = Arg3
>         Local1 = 0x00
>         Local2 = 0x00
>         While (Local0)
>         {
>             Local2 = (Local1 * 0x04)
>             CreateDWordField (BUF1, Local2, CAPB)
>             If (Arg2)
>             {
>                 CAPB &= 0xFFFFFFFC
>                 CAPB |= 0x00
>             }
>             Else
>             {
>             }
>     
>             Local1++
>             Local0--
>         }
>     
>         Return (BUF1) /* \_SB_.PCI0._OSC.BUF1 */
>     }

*** This bug has been marked as a duplicate of bug 23442 ***

Comment 6 magiblot 2018-09-19 20:49:13 UTC

Finally, let me correct a typo. In comment #4, when I said:

> makes the processor behave the same as in Linux.

I meant Windows.

Comment 7 magiblot 2018-09-19 20:51:07 UTC

Comment on attachment 278543 [details]
output of acpidump

Corrected MIME type of attachment 278543 [details]