Bug 62181 - ASPM not working on Lenovo x230
Summary: ASPM not working on Lenovo x230
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-27 01:19 UTC by John
Modified: 2014-05-07 03:03 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.12-rc2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpi dump (367.50 KB, application/octet-stream)
2013-09-27 01:19 UTC, John
Details
dmesg dump (63.74 KB, application/octet-stream)
2013-09-27 01:20 UTC, John
Details
ACPI dump from ver. 20130823 (384.35 KB, application/octet-stream)
2013-09-27 03:53 UTC, John
Details
disassembled FADT (9.56 KB, application/octet-stream)
2013-09-27 04:55 UTC, Lv Zheng
Details
[DBG PATCH] PCIe: Add log to indicate no-op of ASPM disabling. (1.14 KB, patch)
2013-10-14 08:48 UTC, Lv Zheng
Details | Diff
[DBG PATCH] ACPI/MCFG: Add re-enumeration support for MCFG entries. (1.99 KB, patch)
2013-10-16 02:29 UTC, Lv Zheng
Details | Diff
[DBG PATCH 2/2] ACPI/MCFG: Add reservation support for MCFG entries. (6.03 KB, application/x-zip-compressed)
2013-10-16 02:31 UTC, Lv Zheng
Details
Zapped DSDT containing useful information related to MMCONFIG. (15.11 KB, application/octet-stream)
2013-10-16 07:30 UTC, Lv Zheng
Details
dmesg from 3.12-rc5 with pcie_aspm=force (64.75 KB, text/plain)
2013-10-16 21:42 UTC, John
Details
dmesg from 3.12-rc5 without pcie_aspm=force (76.10 KB, text/plain)
2013-10-16 21:43 UTC, John
Details
lspci -vv from 3.12-rc5 with pcie_aspm=force (19.75 KB, text/plain)
2013-10-16 21:43 UTC, John
Details
lspci -vv from 3.12-rc5 without pcie_aspm=force (19.75 KB, text/plain)
2013-10-16 21:44 UTC, John
Details
lspci -vv w. pcie_aspm=force & PCIe PM disabled in the BIOS (19.38 KB, application/octet-stream)
2014-05-07 02:04 UTC, Rob
Details
lspci -vv w. pcie_aspm=force & PCIe PM enabled in the BIOS (19.37 KB, application/octet-stream)
2014-05-07 02:05 UTC, Rob
Details
lspci -vv without pcie_aspm=force & PCIe PM enabled in the BIOS (19.39 KB, application/octet-stream)
2014-05-07 02:06 UTC, Rob
Details

Description John 2013-09-27 01:19:26 UTC
Created attachment 109731 [details]
acpi dump

ASPM isn't working on my Lenovo x230. The BIOS? firmware? version is 2.56, with PCIe power management enabled in the UEFI menu. The system is booting from UEFI without CSM.

With ASPM forced, it fails after these messages:

[    0.227213] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

[    0.323125] acpi PNP0A08:00: Requesting ACPI _OSC control (0x1d)
[    0.323308] acpi PNP0A08:00: ACPI _OSC request failed (AE_SUPPORT), returned control mask: 0x0d
[    0.323311] acpi PNP0A08:00: ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.323359] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.

acpidump complains "Wrong checksum for FADT!"

Is this an issue with Linux, my configuration, the firmware, or some combination of the three?
Comment 1 John 2013-09-27 01:20:05 UTC
Created attachment 109741 [details]
dmesg dump
Comment 2 Lv Zheng 2013-09-27 03:22:14 UTC
Could you tell me the version of the acpidump you are using?
If you are using the ACPICA one, you should use the one versioned as 20130823.
And if it is an earlier versioned one, please use the newer acpidump and re-post the result again.
Comment 3 John 2013-09-27 03:53:19 UTC
Created attachment 109751 [details]
ACPI dump from ver. 20130823

A very old version, apparently. I was just using the version in the Ubuntu repos.

This new dump is using the ACPICA version, 20130823.
Comment 4 Lv Zheng 2013-09-27 04:55:14 UTC
Created attachment 109761 [details]
disassembled FADT

The error log relates to:
        if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) {
                pr_info("ACPI FADT declares the system doesn't support MSI, so disable it\n");
        }

From the attached disassembled FADT, we can see:
[06Dh 0109   2]   Boot Flags (decoded below) : 0013
               Legacy Devices Supported (V2) : 1
            8042 Present on ports 60/64 (V2) : 1
                        VGA Not Present (V4) : 0
                      MSI Not Supported (V4) : 0
                PCIe ASPM Not Supported (V4) : 1  <- So no ASPM
                   CMOS RTC Not Present (V5) : 0

It's defined in Table 5-36 Fixed ACPI Description Table Boot Architecture Flags of ACPI specification.
PCIe ASPM Controls bit-length=1 bit-offset=4:
If set, indicates to OSPM that it must not enable OSPM ASPM control on this platform.

Linux didn't define a wrong value for it:
#define ACPI_FADT_NO_ASPM           (1<<4)      /* 04: [V4] PCIe ASPM control must not be enabled */

So you may try harder to find a way to enable it in the BIOS setups.
Comment 5 Lv Zheng 2013-09-27 04:59:16 UTC
A mistake here: :)
        if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) {
                pr_info("ACPI FADT declares the system doesn't support MSI, so disable it\n");
        }
Should be:
        if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
                pr_info("ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
        }
Sorry for the noise.
Comment 6 John 2013-09-27 05:24:16 UTC
(In reply to Lv Zheng from comment #4)
> So you may try harder to find a way to enable it in the BIOS setups.

That's why I've opened this. There is only one relevant option, "PCI Express Power management" with the description "Enables or disables a feature that automatically adjusts power management when there is no PCI Express activity. Normally, it is not necessary to change this setting."

Whether it's enabled or disabled, Linux shows the dmesg output from #1.
Comment 7 Lv Zheng 2013-09-27 06:49:29 UTC
You may also need to enable something like "connected standby" or "runtime idle" or likewise.
The PCI PM feature may relies on some generic PM settings in BIOS.

I don't have experiences of using this machine.
Hope some experienced one can offer help.
Comment 8 John 2013-09-27 16:06:50 UTC
The closest option I see to that is a CPU Power Management toggle (as well as speedstep, thermal management etc, full list here: http://www.lenovo.com/shop/americas/content/user_guides/x230_ug_en.pdf), but no combination of options changes the dmesg output.

Forgive my ignorance, is it possible the BIOS is just buggy, and the 'missing support' is overridden by Windows or the Lenovo power management software?
Comment 9 Lv Zheng 2013-10-10 00:58:12 UTC
If you have passed the pcie_aspm=force to the kernel command line, the following error message won't prevent you from enabling ASPM:
[    0.227213] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.323311] acpi PNP0A08:00: ACPI _OSC control for PCIe not granted, disabling ASPM
As pcie_no_aspm() called after such error messages should be no-op for pcie_aspm=force.
Comment 10 Lv Zheng 2013-10-14 08:48:10 UTC
Created attachment 110911 [details]
[DBG PATCH] PCIe: Add log to indicate no-op of ASPM disabling.

This can help you to understand the enabling status of ASPM.
I'm checking with the last error message from your report.
Comment 11 Lv Zheng 2013-10-15 08:08:05 UTC
These lines are suspecious:
[    0.227470] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.227475] PCI: not using MMCONFIG

It seems your platform (probably a hardware reduced platform) is using MCFG:
[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 5B
[00Ah 0010   6]                       Oem ID : "LENOVO"
[010h 0016   8]                 Oem Table ID : "TP-G2   "
[018h 0024   4]                 Oem Revision : 00002560
[01Ch 0028   4]              Asl Compiler ID : "PTL "
[020h 0032   4]        Asl Compiler Revision : 00000002

[024h 0036   8]                     Reserved : 0000000000000000

[02Ch 0044   8]                 Base Address : 00000000F8000000
[034h 0052   2]         Segment Group Number : 0000
[036h 0054   1]             Start Bus Number : 00
[037h 0055   1]               End Bus Number : 3F
[038h 0056   4]                     Reserved : 00000000

But current kernel code can not survive such a situation.
I believe if you call pci_mmcfg_late_init at some point, the last line of the error log can disappear.
Comment 12 Lv Zheng 2013-10-16 02:29:12 UTC
Created attachment 111201 [details]
[DBG PATCH] ACPI/MCFG: Add re-enumeration support for MCFG entries.

This is a solution to re-enumeration MCFG to avoid the last error log entry.
Could you help to test?
Comment 13 Lv Zheng 2013-10-16 02:31:18 UTC
Created attachment 111211 [details]
[DBG PATCH 2/2] ACPI/MCFG: Add reservation support for MCFG entries.

This is another approach to avoid deletion of MCFG entries during kernel boot.
Comment 14 Lv Zheng 2013-10-16 04:47:25 UTC
Sorry for the noise.

[DBG PATCH] ACPI/MCFG: Add re-enumeration support for MCFG entries.
is useless as pci_mmcfg_late_init() is already called in acpi_init().
The following lines might be the result of this fact:
[    0.288246] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.295621] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources

[DBG PATCH 2/2] ACPI/MCFG: Add reservation support for MCFG entries.
may also be useless as interpreter is initialized in acpi_early_init() which is called before any initcalls.

I still don't have idea about what has caused the following error log:
[    0.323359] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
Comment 15 Lv Zheng 2013-10-16 07:13:28 UTC
According to your DSDT, removing the TPM ones, focusing on PNP0A08's WordBusNumber related resource and its fields (it should be _Y25, B0MX and B0LN), we got the following zapped DSDT (I didn't include PNP0C01/PNP0C02 _CRS in this DSDT):

DefinitionBlock ("./dsdt.aml", "DSDT", 1, "LENOVO", "TP-G2   ", 0x00002560)
{
    Scope (\_SB)
    {
        Device (PCI0)
        {
            Name (_BBN, 0x00)  // _BBN: BIOS Bus Number
            Name (_ADR, 0x00)  // _ADR: Address
            Name (RID, 0x00)
            Name (_S3D, 0x02)  // _S3D: S3 Device State

            Name (_HID, EisaId ("PNP0A08"))  // _HID: Hardware ID
            Name (_CID, EisaId ("PNP0A03"))  // _CID: Compatible ID

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
                    0x0000,             // Granularity
                    0x0000,             // Range Minimum
                    0x00FF,             // Range Maximum
                    0x0000,             // Translation Offset
                    0x0100,             // Length
                    ,, _Y25)
            })
            CreateWordField (_CRS, \_SB.PCI0._Y25._MAX, B0MX)  // _MAX: Maximum Base Address
            CreateWordField (_CRS, \_SB.PCI0._Y25._LEN, B0LN)  // _LEN: Length
            Method (_INI, 0, Serialized)  // _INI: Initialize
            {
                Store (0x3F, B0MX)
                Store (Add (0x3F, 0x01), B0LN)
            }
        }
    }
}

B0MX/B0LN can be used to modify the following WordBusNumber resource's fields: Range Maximum/Length.  There is no other B0MX/B0LN modifications in the original DSDT.  So after initialization, BusNr of bridge PNP0A08 is 0x00-0x3f/0x40.

According to your log:
1. these lines indicate the insertion of the motherboard resource:
[    0.288246] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.295621] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources
2. this line tells us the BusNr Linux is checking:
[    0.322935] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f])

I couldn't find any possibility that the resource could be deleted between these two steps in the vanilla kernel.  Thus the final error log entry looks weird to me.

I'm going to ask someone to double check my investigation result.
Comment 16 Lv Zheng 2013-10-16 07:30:58 UTC
Created attachment 111261 [details]
Zapped DSDT containing useful information related to MMCONFIG.

The attached file is a zapped DSDT that might be useful for others that are watching this thread.
It contains:
 PNP0C01/PNP0C02 _CRS.
 PNP0A08 _CRS/_INI/_OSC.
 There is no _CBA in the original DSDT.
Linux adds MCFG/_CBA described entries into the motherboard resource list (pci_mmcfg_list), and deletes them if they are not in _CRS of the PNP0C01/PNP0C02.  For bridge device like PNP0A08, Linux checks if the WordBusNumber indicated resource can be found in the motherboard resource list.  The error log entry happens when it is not found.
Comment 17 John 2013-10-16 21:41:24 UTC
Hopefully this doesn't muddy things further. I made a couple BIOS changes that didn't seem to have any effect (I can provide another ACPI dump if you need), and I've been tracking the 3.12 RCs, I'm on 3.12-rc5 now.

Things have gotten a bit weird though: pcie_aspm=force seems to disable ASPM on the devices, whereas leaving the option out enables it (at least, as shown in lspci -vv)

I'm also no longer getting this line:

[    0.323359] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.

I will attach the new dmesg and lspci outputs.
Comment 18 John 2013-10-16 21:42:37 UTC
Created attachment 111421 [details]
dmesg from 3.12-rc5 with pcie_aspm=force
Comment 19 John 2013-10-16 21:43:10 UTC
Created attachment 111431 [details]
dmesg from 3.12-rc5 without pcie_aspm=force
Comment 20 John 2013-10-16 21:43:50 UTC
Created attachment 111441 [details]
lspci -vv from 3.12-rc5 with pcie_aspm=force
Comment 21 John 2013-10-16 21:44:10 UTC
Created attachment 111451 [details]
lspci -vv from 3.12-rc5 without pcie_aspm=force
Comment 22 Lv Zheng 2013-10-17 00:57:12 UTC
Thanks for reporting.

I'm glad that the confusions of the error messages are all cleared.

For the new results, the difference is:
If aspm=force is specified, then Linux will take over the ownership of ASPM from BIOS.
If aspm=force isn't specified, then Linux will not do this, and BIOS can enable it for you.
Thus this looks like there is some weakness in the Linux ASPM implementation as it cannot enable ASPM without BIOS support.

You might be able to verify this conclusion by disbling PCIe power management related BIOS features and lspci again.  If you still can see the following lines in the log, then it is likely that the ASPM is disabled in the lspci output:
[    0.195604] acpi PNP0A08:00: Requesting ACPI _OSC control (0x1d)
[    0.195680] acpi PNP0A08:00: ACPI _OSC request failed (AE_SUPPORT), returned control mask: 0x0d
[    0.195681] acpi PNP0A08:00: ACPI _OSC control for PCIe not granted, disabling ASPM

I'm not an expert of PCIe/ASPM, it'll take me some time to go through the ASPM specification before helping you.

You can either wait for the responses from our team or you can also find a PCIe power guys to give you a reasonable explaination.
Comment 23 John 2013-10-17 01:39:44 UTC
(In reply to Lv Zheng from comment #22)
> If aspm=force is specified, then Linux will take over the ownership of ASPM
> from BIOS.
> If aspm=force isn't specified, then Linux will not do this, and BIOS can
> enable it for you.
> Thus this looks like there is some weakness in the Linux ASPM implementation
> as it cannot enable ASPM without BIOS support.

It think it's the opposite: the only difference between those two dmesg/lspci outputs is the pcie_aspm=force option, the BIOS option was untouched (PCIe power management turned on.)

When aspm=force is specified, Linux doesn't seem to be handling it properly (ASPM disabled.)
When aspm=force is unspecified, something (the BIOS?) seems to be setting it up.

It seems odd, to say the least, that forcing it on forces it off :)

> You might be able to verify this conclusion by disbling PCIe power
> management related BIOS features and lspci again.  If you still can see the
> following lines in the log, then it is likely that the ASPM is disabled in
> the lspci output:
> [    0.195604] acpi PNP0A08:00: Requesting ACPI _OSC control (0x1d)
> [    0.195680] acpi PNP0A08:00: ACPI _OSC request failed (AE_SUPPORT),
> returned control mask: 0x0d
> [    0.195681] acpi PNP0A08:00: ACPI _OSC control for PCIe not granted,
> disabling ASPM

I'll try this later tonight and report back.
Comment 24 Lv Zheng 2013-12-05 07:41:49 UTC
Any updates?
Comment 25 Lv Zheng 2013-12-11 06:46:32 UTC
Close due to no further investigation result.
You can re-open it if issues are still there.
Comment 26 Rob 2014-05-07 02:04:03 UTC
Created attachment 135271 [details]
lspci -vv w. pcie_aspm=force & PCIe PM disabled in the BIOS
Comment 27 Rob 2014-05-07 02:05:31 UTC
Created attachment 135281 [details]
lspci -vv w. pcie_aspm=force & PCIe PM enabled in the BIOS
Comment 28 Rob 2014-05-07 02:06:38 UTC
Created attachment 135291 [details]
lspci -vv without pcie_aspm=force & PCIe PM enabled in the BIOS
Comment 29 Rob 2014-05-07 02:21:05 UTC
(In reply to Lv Zheng from comment #22)
> Thanks for reporting.
> 
> I'm glad that the confusions of the error messages are all cleared.
> 
> For the new results, the difference is:
> If aspm=force is specified, then Linux will take over the ownership of ASPM
> from BIOS.
> If aspm=force isn't specified, then Linux will not do this, and BIOS can
> enable it for you.
> Thus this looks like there is some weakness in the Linux ASPM implementation
> as it cannot enable ASPM without BIOS support.
> 
> You might be able to verify this conclusion by disbling PCIe power
> management related BIOS features and lspci again.  If you still can see the
> following lines in the log, then it is likely that the ASPM is disabled in
> the lspci output:
> [    0.195604] acpi PNP0A08:00: Requesting ACPI _OSC control (0x1d)
> [    0.195680] acpi PNP0A08:00: ACPI _OSC request failed (AE_SUPPORT),
> returned control mask: 0x0d
> [    0.195681] acpi PNP0A08:00: ACPI _OSC control for PCIe not granted,
> disabling ASPM
> 
> I'm not an expert of PCIe/ASPM, it'll take me some time to go through the
> ASPM specification before helping you.
> 
> You can either wait for the responses from our team or you can also find a
> PCIe power guys to give you a reasonable explaination.

dmesg return the same thing regardless of if I have:
PCIe enabled in the BIOS &w. pcie_aspm=force
PCIe enabled in the BIOS & without pcie_aspm=force
PCIe disabled in the BIOS & w. pcie_aspm=force

[    0.277179] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.277370] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability]
[    0.277455] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability]
[    0.277460] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability]
[    0.277463] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER]
[    0.277466] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM
[    2.744129] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5

but theres a few diff. in the attached lspci output. Please take a look and let me know what I can do to help you.
Comment 30 Rob 2014-05-07 03:03:45 UTC
s/PCIe/PCI PM

Looks like theres no difference in lspci between PCIe PM enabled with or without pcie_aspm=force but my power consumption is worse when its forced?

PCIe PM enabled without pcie_aspm=force:
Summary:
  5.32 Watts on Average with Standard Deviation 0.09 

PCIe PM enabled with pcie_aspm=force:
Summary:
  6.27 Watts on Average with Standard Deviation 0.65

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