13.2 DMESG Error and Warnings Optimus Laptop

DMESG Error

acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM

Note: Active State Power Management (ASPM) is a power management protocol used to manage PCI Express-based (PCIe) serial link devices as links become less active over time. It is normally used on laptops and other mobile Internet devices to extend battery life.

DMESG Warnings

1.  ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)

2.  ACPI Warning: SystemIO range 0x0000000000006040-0x000000000000605f conflicts with OpRegion 0x0000000000006040-0x000000000000604f (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258)
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

3.   bbswitch: Found discrete VGA device 0000:0a:00.0: \_SB_.PCI0.RP05.PEGP
    2.912250] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
    2.912362] bbswitch: detected an Optimus _DSM function
    2.912375] pci 0000:0a:00.0: enabling device (0006 -> 0007)
    2.912433] bbswitch: disabling discrete graphics
    2.912440] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)

Looks like I need to explore my DSDT:P

I found some info:
The motherboard. More specifically, the BIOS. It is only saying that ASPM ( power saving mode for the pcie bus when it is idle ) is being disabled as a result, so just ignore it.

The kernel is reporting that the firmware has refused to pass control of PCIe functionality to the kernel. _OSC is an ACPI control method that the kernel uses to see if the firmware (BIOS) will allow it to control PCIe Active State Power Management (amongst other things).
This is just a warning message and not a bug.

And, a possible fix: "Patch set updated for coreboot: fe487f6 Persimmon DSDT: Add OSC method at:

https://www.mail-archive.com/coreboot@coreboot.org/msg40313.html

Before this change, dmesg gave this message:
    
    pci0000:00: Requesting ACPI _OSC control (0x1d)
    pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 
0x1d
    ACPI _OSC control for PCIe not granted, disabling ASPM
    
    After this change, dmesg looks like this:
    
    pci0000:00: Requesting ACPI _OSC control (0x1d)
    pci0000:00: ACPI _OSC control (0x1d) granted
    
    Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2
    Signed-off-by: Mike Loptien <mike.lopt...@se-eng.com>
---
 src/mainboard/amd/persimmon/dsdt.asl | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/mainboard/amd/persimmon/dsdt.asl 
b/src/mainboard/amd/persimmon/dsdt.asl
index 148d7b0..d29bbff 100644
--- a/src/mainboard/amd/persimmon/dsdt.asl
+++ b/src/mainboard/amd/persimmon/dsdt.asl
@@ -1157,8 +1157,20 @@ DefinitionBlock (
                Device(PCI0) {
                        External (TOM1)
                        External (TOM2)
-                       Name(_HID, EISAID("PNP0A03"))
+                       Name(_HID, EISAID("PNP0A08"))   /* PCI Express Root 
Bridge */
+                       Name(_CID, EISAID("PNP0A03"))   /* PCI Root Bridge */
                        Name(_ADR, 0x00180000)  /* Dev# = BSP Dev#, Func# = 0 */
+
+                       /* Operating System Capabilities Method */
+                       Method(_OSC, 4)
+                       {       /* Check for proper PCI/PCIe UUID */
+                               
If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766")))
+                               {
+                                       /* Let OS control everything */
+                                       Return (Arg3)
+                               }
+                       }
+
                        Method(_BBN, 0) { /* Bus number = 0 */
                                Return(0)
                        }

I really won’t know until I get in and look at my DSDT.

Actually, the errror is not bothering anything! I’m going to leave this until I install 13.2 GA and as I have to go on the road this week, that may be a while. Fixing the DSDT takes me a while – learninng curve, like making it work with Grub2 for one – sounds like a project for a bad winter’s day. In the meantime, I can be looking for fixes for those warnings which may be as easy as searching the spec.

Have fun!

Oops, I forgot to add:

Linux also provides some ASPM driver kernel parameters to allow some level of tweakability. The following kernel parameters can be used:

disable ASPM: pcie_aspm=off

use default firmware configuration: pcie_aspm=default

disables ASPM and clock power management: pcie_aspm=performance

highest power saving mode, enable ASPM and clock power management: pcie_aspm=powersave

force ASPM on: pcie_aspm=force

Which I will test as kernel parameters in the meantime

Anything to report? I have the same on my optimus laptop.

No, I have not had the time to get that deep into it (what with uefi + secure boot). I’ll be on the road until the Holidays – maybe during a cold, winter’s long weekend.

Actually, my laptop is running very well with 13.2, so, I am in no hurry. I did try those kernel parameters to no avail (some just made things worse).
Should I find any code solutions, I will surely post them.

I also tried the kernel parameters and they didn’t seem to help at all. I still have the acpi error, but, other than not having any kind of power saving, it runs fine (doesn’t recognize when i am on battery, etc.).

I’m glad I waited as I checked HP for updates & there was a BIOS update which I just applied – I’ll recheck and post when able.

[QUOTE=snakedriver;2679018]there was a BIOS update which I just applied – I’ll recheck and post when able.[/QUOtTE]

OK, 1st boot after the BIOS update took a little longer, but was reasonable; then I did an online update and rebooted; 2nd boot was much faster.

I now have the following DMESG errors:

nvidia: probe of 0000:0a:00.0 failed with error -1
NVRM: The NVIDIA probe routine failed for 1 device(s).
NVRM: None of the NVIDIA graphics adapters were initialized!
[drm] Module unloaded
sd 0:0:0:0: Attached scsi generic sg0 type 0
sr 1:0:0:0: Attached scsi generic sg1 type 5
NVRM: NVIDIA init module failed!
INFO @wl_cfg80211_attach : Registered CFG80211 phy

and

 \_SB_.PCI0:_OSC invalid UUID
    0.719501] _OSC request data:1 1f 0 
    0.719505] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM

Not bad!
That first error is most likely caused by me having had nvidia bumblebee installed and I was experimenting to see if nouveau bumblebee would work having looked at the code in bumblebee.config. A nvidia bumblebee re-install will most likely make that go away.

Plus, I think that the _OSC failed (AE_ERROR) is fixable in DSDT.

I now have the following DMESG Warnings:

bbswitch: Found discrete VGA device 0000:0a:00.0: \_SB_.PCI0.RP05.PEGP
ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
bbswitch: detected an Optimus _DSM function
pci 0000:0a:00.0: enabling device (0006 -> 0007)
bbswitch: disabling discrete graphics
ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)

and

ACPI Warning: SystemIO range 0x0000000000006040-0x000000000000605f conflicts with OpRegion 0x0000000000006040-0x000000000000604f (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258)
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

I think the 1st will go away when I work on bumblebee.

It will be fun seeing if I can find the fixes when I have the time which may well be after the Holidays.

Have fun!

I have had an opportunity to look at my DSDT on my HP 17T Optimus laptop. I will continue in a series of posts; let’s get started:

!st, I want to know what compiled the original code? Check if system’s DSDT was compiled using Intel or Microsoft compiler (INTL or MSFT)?

# dmesg|grep DSDT 
    0.000000] ACPI: DSDT 0x000000009CFE3000 011187 (v01 HPQOEM SLIC-MPC 00000000 ACPI 00040000)

Ha, it’s HP = HPQOEM; (at least they were on the team that helped write the Intel spec.

2nd. the DSDT does not reside in the same location as in earlier opensuse versions when I did this before. So, I use “Find Files & Folders”, set to search from “/” and all subfolders, go get a cup of coffee:

file:///sys/firmware/acpi/tables/DSDT
file:///usr/src/linux-3.16.6-2-obj/x86_64/xen/include/config/acpi/custom/dsdt
file:///usr/src/linux-3.16.6-2-obj/x86_64/default/include/config/acpi/custom/dsdt
file:///usr/src/linux-3.16.6-2-obj/x86_64/desktop/include/config/acpi/custom/dsdt

3rd, as I don’t wish to go messing up my system, I move DSDT into /home/myname as uncompiled dsdt.dat (and move the Intel Spec “iasl” tool which resides in /usr/bin which I place in /home/myname/bin). Now I’m ready to proceed:

# cat /sys/firmware/acpi/tables/DSDT > /home/myname/dsdt.dat
linux-71uc:~ # cd /usr/bin
linux-71uc:/usr/bin # ./iasl -d /home/myname/dsdt.dat

Pay close attention, that yields:

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140724-64
Copyright (c) 2000 - 2014 Intel Corporation

Loading Acpi table from file /home/jim/dsdt.dat - Length 00070023 (011187)
ACPI: DSDT 0x0000000000000000 011187 (v01 HPQOEM SLIC-MPC 00000000 ACPI 00040000)
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Found 12 external control methods, reparsing with new information
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    /home/jim/dsdt.dsl - 652847 bytes

iASL Warning: There were 12 external control methods found during
disassembly, but additional ACPI tables to resolve these externals
were not specified. The resulting disassembler output file may not
compile because the disassembler did not know how many arguments
to assign to these methods. To specify the tables needed to resolve
external control method references, the -e option can be used to
specify the filenames. Example iASL invocations:
    iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
    iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
    iasl -e ssdt*.aml -d dsdt.aml                                                                                                                                  
                                                                                                                                                                   
In addition, the -fe option can be used to specify a file containing                                                                                               
control method external declarations with the associated method                                                                                                    
argument counts. Each line of the file must be of the form:                                                                                                        
    External (<method pathname>, MethodObj, <argument count>)                                                                                                      
Invocation:                                                                                                                                                        
    iasl -fe refs.txt -d dsdt.aml    

Let’s examine the above statement:

“Warning: There were 12 external control methods found”
When I go look at file:///sys/firmware/acpi/tables/, I find that there are 6 SSDT’s and a folder “Dynamic” with 3 more SSDT’s and a total of 23 files there.

“The resulting disassembler output file may not compile because the disassembler did not know how many arguments to assign to these methods.”

The key IMHO is the word “Dynamic” as the code is inter-related to many of the other tables. When I look at the dsdt code, there are areas colored tan, red, blue, etc and some code phrases don’t show when I compile – I will point these out as I layout what I have done so far.

For those looking for a quick solution, you can stop here as I have been unsuccessful in getting the entire dsdt to compile. For those interested in helping, I have been successful in getting all element errors to compile, but when I put them together, it fails.

More to come…

OK, let’s do some compiling:

/home/myname/bin/iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140724-64
Copyright (c) 2000 - 2014 Intel Corporation

Compiler aborting due to parser-detected syntax error(s)
dsdt.dsl   9943:                 Store (\_GPE.MMTB (Local2, \_GPE.OSUP (Local2)), Store (Local1, REG6) )
Error    6126 -                               syntax error, unexpected PARSEOP_STORE ^ 

dsdt.dsl  10461:                 Store (\_GPE.MMTB (Local3, \_GPE.OSUP (Local3)), Store (Local2, REG6) )
Error    6126 -                               syntax error, unexpected PARSEOP_STORE ^ 

ASL Input:     dsdt.dsl - 16350 lines, 581363 bytes, 7533 keywords
Hex Dump:      dsdt.hex - 171 bytes

Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
linux-71uc:/home/jim # 

Well, only 2 errors which looks easy to fix; but, Let’s look at the code:

If (LOr (LEqual (BID, BICO), LEqual (BID, BICC)))
            {
                Acquire (OSUM, 0xFFFF)
                Store (MMRP (), Local0)
                OperationRegion (RP_X, SystemMemory, Local0, 0x20)
                Field (RP_X, DWordAcc, NoLock, Preserve)
                {
                    REG0,   32, 
                    REG1,   32, 
                    REG2,   32, 
                    REG3,   32, 
                    REG4,   32, 
                    REG5,   32, 
                    REG6,   32, 
                    REG7,   32
                }

                Store (REG6, Local1)
                Store (0x00F0F000, REG6) /* \_WAK.REG6 */
                Store (\_GPE.MMTB (Local2, \_GPE.OSUP (Local2)), Store (Local1, REG6) /* \_WAK.REG6 */)  <---line 9943
                Release (OSUM)
            }

and

         If (LOr (LEqual (BID, BICO), LEqual (BID, BICC)))
            {
                Acquire (OSUM, 0xFFFF)
                Store (MMRP (), Local1)
                OperationRegion (RP_X, SystemMemory, Local1, 0x20)
                Field (RP_X, DWordAcc, NoLock, Preserve)
                {
                    REG0,   32, 
                    REG1,   32, 
                    REG2,   32, 
                    REG3,   32, 
                    REG4,   32, 
                    REG5,   32, 
                    REG6,   32, 
                    REG7,   32
                }

                Store (REG6, Local2)
                Store (0x00F0F000, REG6) /* \_SB_.PCI0._INI.REG6 */
                Store (\_GPE.MMTB (Local3, \_GPE.OSUP (Local3)), Store (Local2, REG6) /* \_SB_.PCI0._INI.REG6 */)  <--line 10461
                Release (OSUM)
                Acquire (WFDM, 0xFFFF)
                Store (One, WKFN) /* \WKFN */
                Release (WFDM)
            }
        }

Note the difference in the error report code and the dsdt.dsl code lines 9943 and 10461; I think I have lines that fall into that “Dynamic” category.

I have google searched for those two errors and found that those two error lines are common with many laptop brands.
Some solutions state to simply delete the offending lines, but, when I do that on my 17T Optimus, it throws errors and pages of warnings; so far, I have to have those lines of code; ergo fix them.

More ramblings to come…

Let’s work on the offending lines of code:


Store (\_GPE.MMTB (Local2, \_GPE.OSUP (Local2)), Store (Local1, REG6) /* \_WAK.REG6 */)

New effort

Store (REG6, Local1)
                Store (0x00F0F000, REG6) /* \_WAK.REG6 */
                Store (\_GPE.MMTB(), Local2)
		\_GPE.OSUP (Local2) 
		Store (Local1, REG6) /* \_WAK.REG6 */
                Release (OSUM)
            }

That compiles successfully as:

/home/jim/bin/iasl -tc /home/jim/dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140724-64
Copyright (c) 2000 - 2014 Intel Corporation

Compiler aborting due to parser-detected syntax error(s)
/home/jim/dsdt.dsl  10463:                 Store (\_GPE.MMTB (Local3, \_GPE.OSUP (Local3)), Store (Local2, REG6) )
Error    6126 -                                         syntax error, unexpected PARSEOP_STORE ^ 

ASL Input:     /home/jim/dsdt.dsl - 16352 lines, 581366 bytes, 7533 keywords
Hex Dump:      /home/jim/dsdt.hex - 181 bytes

Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

Now if I leave line 9943 in it’s original form and work on line 10461


Store (\_GPE.MMTB (Local3, \_GPE.OSUP (Local3)), Store (Local2, REG6) /* \_SB_.PCI0._INI.REG6 */)

New effort:

Store (REG6, Local2)
                Store (0x00F0F000, REG6) /* \_SB_.PCI0._INI.REG6 */
                Store (\_GPE.MMTB(), Local3)				  
                \_GPE.OSUP (Local3) 
                Store (Local2, REG6) /* \_SB_.PCI0._INI.REG6 */
                Release (OSUM) 

It compiles showing the error of line 9943.

However, when I do both, it won’t compile at all

For now, it’s back to the drawing board and that original decompile:

To specify the tables needed to resolve
external control method references, the -e option can be used to
specify the filenames. Example iASL invocations:
    iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
    iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
    iasl -e ssdt*.aml -d dsdt.aml                                                                                                                                  
                                                                                                                                                                   
In addition, the -fe option can be used to specify a file containing                                                                                               
control method external declarations with the associated method                                                                                                    
argument counts. Each line of the file must be of the form:                                                                                                        
    External (<method pathname>, MethodObj, <argument count>)                                                                                                      
Invocation:                                                                                                                                                        
    iasl -fe refs.txt -d dsdt.aml       

That may be beyond my knowledge level At least it’s going to take me some time.
Any help appreciated;)

After some searching, I think I finally found info to get started; what follows is an extract"

This thread explains about how to get the dump files needed for both DSDT/SSDT patching from Linux

**STEPS TO GET THE DUMP FROM **LINUX:
How to extract DSDT and SSDT files from Linux using acpi commands:

  1. First you need to install the following two programs to get the dump.
    **acpidump:
    and
    **iasl:

(1st, we know from before that "iasl " resides in /usr/bin in root

2nd, a search shows that “acpidump” is a tool of “acpia” which was installed by default, and a search shows that “acpidump” resides in /usr/sbin as root)

  1. Open Terminal and enter the following commands one by one to get the DSDT and SSDT dump files
    [CODEacpidump > acpidump.out
    acpixtract -a acpidump.out
    iasl -d DSDT.dat


It also adds:
[b]How to dump System Devices info from Linux using lspci command:
1. Open Terminal and enter the following command to get the devices info dump lspci -nn 2. Save the output of the above command in a text file

For those interested, here are a few links worth reading:
http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://wenku.baidu.com/view/70a6b8daad51f01dc281f1c1.html&prev=search
https://01.org/linux-acpi/documentation/overriding-dsdt    --&gt; look around in there
http://www.insanelymac.com/forum/topic/301908-why-you-need-proper-aml-disassembly/
https://bugzilla.kernel.org/show_bug.cgi?id=3774  ---&gt; worth reading for comments like, 
"If you have multiple SSDTs, you must merge
them into a single AmlCode file. If you choose to overwrite SSDT, ACPI will not
use any SSDT in the BIOS, only uses the one you provided."

I'll keep searching as time permits. but, it'll probably be after the Holidays before I can make a serious attempt.