I'm announcing the release of the 3.2.5 kernel.
It contains one PCI patch, it is up to you to decide to upgrade or not.
The updated 3.2.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
drivers/acpi/pci_root.c | 7 +++++
drivers/pci/pci-acpi.c | 1
drivers/pci/pcie/aspm.c | 58 +++++++++++++++++++++++++++++------------------
include/linux/pci-aspm.h | 4 +--
5 files changed, 47 insertions(+), 25 deletions(-)
Greg Kroah-Hartman (1):
Linux 3.2.5
Matthew Garrett (1):
PCI: Rework ASPM disable code
diff --git a/Makefile b/Makefile
index c8e187e..e9dd0ff 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 2
-SUBLEVEL = 4
+SUBLEVEL = 5
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 2672c79..7aff631 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -596,6 +596,13 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
if (ACPI_SUCCESS(status)) {
dev_info(root->bus->bridge,
"ACPI _OSC control (0x%02x) granted\n", flags);
+ if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
+ /*
+ * We have ASPM control, but the FADT indicates
+ * that it's unsupported. Clear it.
+ */
+ pcie_clear_aspm(root->bus);
+ }
} else {
dev_info(root->bus->bridge,
"ACPI _OSC request failed (%s), "
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 4ecb640..c8e7585 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -395,7 +395,6 @@ static int __init acpi_pci_init(void)
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
printk(KERN_INFO"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
- pcie_clear_aspm();
pcie_no_aspm();
}
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index cbfbab1..1cfbf22 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -68,7 +68,7 @@ struct pcie_link_state {
struct aspm_latency acceptable[8];
};
-static int aspm_disabled, aspm_force, aspm_clear_state;
+static int aspm_disabled, aspm_force;
static bool aspm_support_enabled = true;
static DEFINE_MUTEX(aspm_lock);
static LIST_HEAD(link_list);
@@ -500,9 +500,6 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
int pos;
u32 reg32;
- if (aspm_clear_state)
- return -EINVAL;
-
/*
* Some functions in a slot might not all be PCIe functions,
* very strange. Disable ASPM for the whole slot
@@ -574,9 +571,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
pdev->pcie_type != PCI_EXP_TYPE_DOWNSTREAM)
return;
- if (aspm_disabled && !aspm_clear_state)
- return;
-
/* VIA has a strange chipset, root port is under a bridge */
if (pdev->pcie_type == PCI_EXP_TYPE_ROOT_PORT &&
pdev->bus->self)
@@ -608,7 +602,7 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
* the BIOS's expectation, we'll do so once pci_enable_device() is
* called.
*/
- if (aspm_policy != POLICY_POWERSAVE || aspm_clear_state) {
+ if (aspm_policy != POLICY_POWERSAVE) {
pcie_config_aspm_path(link);
pcie_set_clkpm(link, policy_to_clkpm_state(link));
}
@@ -649,8 +643,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
struct pci_dev *parent = pdev->bus->self;
struct pcie_link_state *link, *root, *parent_link;
- if ((aspm_disabled && !aspm_clear_state) || !pci_is_pcie(pdev) ||
- !parent || !parent->link_state)
+ if (!pci_is_pcie(pdev) || !parent || !parent->link_state)
return;
if ((parent->pcie_type != PCI_EXP_TYPE_ROOT_PORT) &&
(parent->pcie_type != PCI_EXP_TYPE_DOWNSTREAM))
@@ -734,13 +727,18 @@ void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
* pci_disable_link_state - disable pci device's link state, so the link will
* never enter specific states
*/
-static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
+static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
+ bool force)
{
struct pci_dev *parent = pdev->bus->self;
struct pcie_link_state *link;
- if (aspm_disabled || !pci_is_pcie(pdev))
+ if (aspm_disabled && !force)
+ return;
+
+ if (!pci_is_pcie(pdev))
return;
+
if (pdev->pcie_type == PCI_EXP_TYPE_ROOT_PORT ||
pdev->pcie_type == PCI_EXP_TYPE_DOWNSTREAM)
parent = pdev;
@@ -768,16 +766,31 @@ static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
void pci_disable_link_state_locked(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, false);
+ __pci_disable_link_state(pdev, state, false, false);
}
EXPORT_SYMBOL(pci_disable_link_state_locked);
void pci_disable_link_state(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, true);
+ __pci_disable_link_state(pdev, state, true, false);
}
EXPORT_SYMBOL(pci_disable_link_state);
+void pcie_clear_aspm(struct pci_bus *bus)
+{
+ struct pci_dev *child;
+
+ /*
+ * Clear any ASPM setup that the firmware has carried out on this bus
+ */
+ list_for_each_entry(child, &bus->devices, bus_list) {
+ __pci_disable_link_state(child, PCIE_LINK_STATE_L0S |
+ PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM,
+ false, true);
+ }
+}
+
static int pcie_aspm_set_policy(const char *val, struct kernel_param *kp)
{
int i;
@@ -935,6 +948,7 @@ void pcie_aspm_remove_sysfs_dev_files(struct pci_dev *pdev)
static int __init pcie_aspm_disable(char *str)
{
if (!strcmp(str, "off")) {
+ aspm_policy = POLICY_DEFAULT;
aspm_disabled = 1;
aspm_support_enabled = false;
printk(KERN_INFO "PCIe ASPM is disabled\n");
@@ -947,16 +961,18 @@ static int __init pcie_aspm_disable(char *str)
__setup("pcie_aspm=", pcie_aspm_disable);
-void pcie_clear_aspm(void)
-{
- if (!aspm_force)
- aspm_clear_state = 1;
-}
-
void pcie_no_aspm(void)
{
- if (!aspm_force)
+ /*
+ * Disabling ASPM is intended to prevent the kernel from modifying
+ * existing hardware state, not to clear existing state. To that end:
+ * (a) set policy to POLICY_DEFAULT in order to avoid changing state
+ * (b) prevent userspace from changing policy
+ */
+ if (!aspm_force) {
+ aspm_policy = POLICY_DEFAULT;
aspm_disabled = 1;
+ }
}
/**
diff --git a/include/linux/pci-aspm.h b/include/linux/pci-aspm.h
index 7cea7b6..c832014 100644
--- a/include/linux/pci-aspm.h
+++ b/include/linux/pci-aspm.h
@@ -29,7 +29,7 @@ extern void pcie_aspm_pm_state_change(struct pci_dev *pdev);
extern void pcie_aspm_powersave_config_link(struct pci_dev *pdev);
extern void pci_disable_link_state(struct pci_dev *pdev, int state);
extern void pci_disable_link_state_locked(struct pci_dev *pdev, int state);
-extern void pcie_clear_aspm(void);
+extern void pcie_clear_aspm(struct pci_bus *bus);
extern void pcie_no_aspm(void);
#else
static inline void pcie_aspm_init_link_state(struct pci_dev *pdev)
@@ -47,7 +47,7 @@ static inline void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
static inline void pci_disable_link_state(struct pci_dev *pdev, int state)
{
}
-static inline void pcie_clear_aspm(void)
+static inline void pcie_clear_aspm(struct pci_bus *bus)
{
}
static inline void pcie_no_aspm(void)
On 06.02.2012 10:16, Greg KH wrote:
> I'm announcing the release of the 3.2.5 kernel.
>
> It contains one PCI patch, it is up to you to decide to upgrade or not.
This one makes my Soundblaster Live (alsa/emu10k1) silent.
It is detected, i can e.g. change the mixer, but i can't hear any sound.
Updating from 3.2.4 the emu10k1 driver was among the few that was
recompiled after the update to 3.2.5. (Technically i look for that when
i downgraded to 3.2.4, but i think there number of recompiled files
should be the same in either direction)
After downgrade to 3.2.4 i have sound again.
There is a difference in syslog output regarding aspm, the emu10k1 line
is the same.
3.2.4:
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
...
ACPI _OSC control for PCIe not granted, disabling ASPM
...
e1000e 0000:03:00.0: Disabling ASPM L1
...
snd_emu10k1 0000:06:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
3.2.5:
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
..
pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
...
pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
...
ACPI _OSC control for PCIe not granted, disabling ASPM
...
e1000e 0000:03:00.0: Disabling ASPM L1
...
snd_emu10k1 0000:06:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
The Mainboard is a Cougar Point H67 Chipset: Gigabyte H67A-UD3H-B3.
CPU is Core Intel i7-2600.
lspci:
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
05:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 10)
06:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
06:02.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
lspci -t:
-[0000:00]-+-00.0
+-01.0-[01]----00.0
+-02.0
+-16.0
+-1a.0
+-1b.0
+-1c.0-[02]--
+-1c.4-[03]----00.0
+-1c.5-[04]----00.0
+-1c.6-[05-06]----00.0-[06]--+-02.0
| \-02.1
+-1d.0
+-1e.0-[07]--
+-1f.0
+-1f.2
\-1f.3
If there is more than can i do, i'm happy to give more details/try
patches ...
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Matthias Schniedermeyer wrote:
> On 06.02.2012 10:16, Greg KH wrote:
>> I'm announcing the release of the 3.2.5 kernel.
>>
>> It contains one PCI patch, it is up to you to decide to upgrade or not.
>
> This one makes my Soundblaster Live (alsa/emu10k1) silent.
> It is detected, i can e.g. change the mixer, but i can't hear any sound.
Back in the PCI days, the Emu10k1 chip was known to be quite inefficient
(many small transfers, and IIRC even latency timer bugs) and to be
problematic when used with other high-bandwidth PCI chips like TV capture
cards.
> There is a difference in syslog output regarding aspm, the emu10k1 line
> is the same.
Your PCIe/PCI bridge (5:0.0, iTE IT8892) which handles the PCI bus is
affected by the change.
I do not know if this is an actual hardware bug, or if the bridge is
just too slow to wake up the PCIe link.
Please show the output of "lspci -v -s 5:0".
> pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
Does this mean that the new kernel _dis_ables ASPM, where it left it
enabled previously?
Please try that kernel parameter.
Regards,
Clemens
On 07.02.2012 11:19, Clemens Ladisch wrote:
> Matthias Schniedermeyer wrote:
> > On 06.02.2012 10:16, Greg KH wrote:
> >> I'm announcing the release of the 3.2.5 kernel.
> >>
> >> It contains one PCI patch, it is up to you to decide to upgrade or not.
> >
> > This one makes my Soundblaster Live (alsa/emu10k1) silent.
> > It is detected, i can e.g. change the mixer, but i can't hear any sound.
>
> Back in the PCI days, the Emu10k1 chip was known to be quite inefficient
> (many small transfers, and IIRC even latency timer bugs) and to be
> problematic when used with other high-bandwidth PCI chips like TV capture
> cards.
>
> > There is a difference in syslog output regarding aspm, the emu10k1 line
> > is the same.
>
> Your PCIe/PCI bridge (5:0.0, iTE IT8892) which handles the PCI bus is
> affected by the change.
>
> I do not know if this is an actual hardware bug, or if the bridge is
> just too slow to wake up the PCIe link.
>
> Please show the output of "lspci -v -s 5:0".
With 3.2.4 running:
lspci -v -s 5:0
05:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev
10) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=05, secondary=06, subordinate=06, sec-latency=32
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fbe00000-fbefffff
Capabilities: <access denied>
> > pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
>
> Does this mean that the new kernel _dis_ables ASPM, where it left it
> enabled previously?
>
> Please try that kernel parameter.
I don't want/need ASPM, disabled is fine with me.
As Far as i understand the change in 3.2.5 it is this:
The ASPM change is meant to make Linux behave more like Windows.
Pre 3.2.5 "ASPM disabled" meant: Linux will explicitly disable ASPM,
even when the ACPI says it is already disabled.
With 3.2.5 "ASPM disabled" means: When the ACPI says ASPM is
disabled Linux will leave it alone, which is what Windows is doing.
The assumption is that explicitly disabling ASPM is more problematic
than doing nothing.
As far as i am concerned i don't want/need ASPM, this system isn't a
Laptop and a watt or more power used is preferrable to the potential
problem with a device that doesn't play nice with ASPM enabled. In this
case the problem appears to be the change how disabled is handled.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 07.02.2012 11:58, Matthias Schniedermeyer wrote:
> On 07.02.2012 11:19, Clemens Ladisch wrote:
> > Matthias Schniedermeyer wrote:
> > > On 06.02.2012 10:16, Greg KH wrote:
> > >> I'm announcing the release of the 3.2.5 kernel.
> > >>
> > >> It contains one PCI patch, it is up to you to decide to upgrade or not.
> > >
> > > This one makes my Soundblaster Live (alsa/emu10k1) silent.
> > > It is detected, i can e.g. change the mixer, but i can't hear any sound.
> >
> > Back in the PCI days, the Emu10k1 chip was known to be quite inefficient
> > (many small transfers, and IIRC even latency timer bugs) and to be
> > problematic when used with other high-bandwidth PCI chips like TV capture
> > cards.
> >
> > > There is a difference in syslog output regarding aspm, the emu10k1 line
> > > is the same.
> >
> > Your PCIe/PCI bridge (5:0.0, iTE IT8892) which handles the PCI bus is
> > affected by the change.
> >
> > I do not know if this is an actual hardware bug, or if the bridge is
> > just too slow to wake up the PCIe link.
> >
> > Please show the output of "lspci -v -s 5:0".
>
> With 3.2.4 running:
> lspci -v -s 5:0
> 05:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev
> 10) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=05, secondary=06, subordinate=06, sec-latency=32
> I/O behind bridge: 0000c000-0000cfff
> Memory behind bridge: fbe00000-fbefffff
> Capabilities: <access denied>
Ups. I did that with my user-account. Now with root:
lspci -v -s 5:0
05:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 10) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=05, secondary=06, subordinate=06, sec-latency=32
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fbe00000-fbefffff
Capabilities: [70] Express PCI/PCI-X Bridge, MSI 00
Capabilities: [90] Power Management version 2
Capabilities: [a0] Subsystem: Gammagraphx, Inc. (or missing ID) Device 0000
Capabilities: [100] Device Serial Number 00-00-00-00-00-00-00-00
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Matthias Schniedermeyer wrote:
> On 07.02.2012 11:19, Clemens Ladisch wrote:
>> Matthias Schniedermeyer wrote:
>>> pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
>>
>> Please try that kernel parameter.
>
> I don't want/need ASPM, disabled is fine with me.
In your case, it appears that sound requires ASPM.
Regards,
Clemens
On 07.02.2012 12:40, Clemens Ladisch wrote:
> Matthias Schniedermeyer wrote:
> > On 07.02.2012 11:19, Clemens Ladisch wrote:
> >> Matthias Schniedermeyer wrote:
> >>> pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
> >>
> >> Please try that kernel parameter.
> >
> > I don't want/need ASPM, disabled is fine with me.
>
> In your case, it appears that sound requires ASPM.
OK. I will try that later today.
But i'm not hopeful because in syslog it says:
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
...
ACPI _OSC control for PCIe not granted, disabling ASPM
So if ACPI doesn't want to relinquish control of ASPM, how is Linux
supposed to enable it?
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Matthias Schniedermeyer wrote:
> On 07.02.2012 12:40, Clemens Ladisch wrote:
>> Matthias Schniedermeyer wrote:
>>> On 07.02.2012 11:19, Clemens Ladisch wrote:
>>>> Matthias Schniedermeyer wrote:
>>>>> pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
>>>>
>>>> Please try that kernel parameter.
>>>
>>> I don't want/need ASPM, disabled is fine with me.
>>
>> In your case, it appears that sound requires ASPM.
>
> OK. I will try that later today.
>
> But i'm not hopeful because in syslog it says:
> ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
> ...
> ACPI _OSC control for PCIe not granted, disabling ASPM
>
> So if ACPI doesn't want to relinquish control of ASPM, how is Linux
> supposed to enable it?
According to your logs, 3.2.4 didn't touch device 5:0, while 3.2.5 does
disable ASPM. (Are there any other messages regarding 0000:05:00.0?)
It appears that this patch introduces new logic that forcibly disables
ASPM on pre-1.1 devices no matter what the BIOS says, although this
breaks your sound.
("Disable" can mean two things, tell the device to not do ASPM, or just
not tell the device anything.)
Regards,
Clemens
On 07.02.2012 13:28, Clemens Ladisch wrote:
> Matthias Schniedermeyer wrote:
> > On 07.02.2012 12:40, Clemens Ladisch wrote:
> >> Matthias Schniedermeyer wrote:
> >>> On 07.02.2012 11:19, Clemens Ladisch wrote:
> >>>> Matthias Schniedermeyer wrote:
> >>>>> pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
> >>>>
> >>>> Please try that kernel parameter.
> >>>
> >>> I don't want/need ASPM, disabled is fine with me.
> >>
> >> In your case, it appears that sound requires ASPM.
> >
> > OK. I will try that later today.
> >
> > But i'm not hopeful because in syslog it says:
> > ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
> > ...
> > ACPI _OSC control for PCIe not granted, disabling ASPM
> >
> > So if ACPI doesn't want to relinquish control of ASPM, how is Linux
> > supposed to enable it?
So i am now running 3.2.5 with pcie_aspm=force and i have sound.
> According to your logs, 3.2.4 didn't touch device 5:0, while 3.2.5 does
> disable ASPM. (Are there any other messages regarding 0000:05:00.0?)
>From the 3.2.5 with pcie_aspm=force this is:
[ 0.792880] pci 0000:05:00.0: [1283:8892] type 1 class 0x000604
[ 0.793040] pci 0000:05:00.0: supports D1 D2
[ 0.793041] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.793047] pci 0000:05:00.0: PME# disabled
[ 0.795440] pci 0000:05:00.0: PCI bridge to [bus 06-06]
[ 0.795485] pci 0000:05:00.0: bridge window [io 0xc000-0xcfff]
[ 0.795491] pci 0000:05:00.0: bridge window [mem 0xfbe00000-0xfbefffff]
[ 0.815911] pci 0000:05:00.0: PCI bridge to [bus 06-06]
[ 0.815949] pci 0000:05:00.0: bridge window [io 0xc000-0xcfff]
[ 0.815994] pci 0000:05:00.0: bridge window [mem 0xfbe00000-0xfbefffff]
[ 0.816484] pci 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 0.816527] pci 0000:05:00.0: setting latency timer to 64
> It appears that this patch introduces new logic that forcibly disables
> ASPM on pre-1.1 devices no matter what the BIOS says, although this
> breaks your sound.
>
> ("Disable" can mean two things, tell the device to not do ASPM, or just
> not tell the device anything.)
As far as i understand the matter the change was supposed to do
"nothing" whereas 3.2.4 did something, but in my case the opposite
happend, whereas 3.2.4 didn't do something that 3.2.5 (without force)
does.
The messages regarding aspm with 3.2.5 and foce are:
dmesg | grep -i aspm
[ 0.000000] Command line: root=/dev/sda2 pcie_aspm=force
[ 0.000000] Kernel command line: root=/dev/sda2 pcie_aspm=force
[ 0.000000] PCIe ASPM is forcibly enabled
[ 0.761782] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.795906] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 1.627705] e1000e 0000:03:00.0: Disabling ASPM L1
[ 4.259301] snd_emu10k1 0000:06:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
I guess this whole mess is Mainboard specifc.
I have a another, very similar system but with an Asus P8H67-M PRO
Mainbaord.
I just remotly booted that machine into 3.2.5, so i can't verify if the
sound works, but as the dmesg-output appears identical to the previous
boot of 3.2.0 so i guess i will work.
This is all i get for the system for aspm
dmesg | grep -i aspm
[ 0.777824] e1000e 0000:02:00.0: Disabling ASPM L0s
So that mainboard has another BIOS/UEFI-Firmware and the
PCIe-PCI-Bridge, the Soundblaster-Live is behind, is from another
manufacture.
lspci -v -s 5:0
05:00.0 PCI bridge: ASMedia Technology Inc. ASM108x PCIe to PCI Bridge Controller (rev 01) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=05, secondary=06, subordinate=06, sec-latency=32
I/O behind bridge: 0000b000-0000bfff
Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 8489
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
[ Matthew wasn't cc'd for this thread - see lkml or ask me or Greg to
forward you the relevant emails ]
On Tue, Feb 7, 2012 at 4:28 AM, Clemens Ladisch <[email protected]> wrote:
>
> According to your logs, 3.2.4 didn't touch device 5:0, while 3.2.5 does
> disable ASPM. ?(Are there any other messages regarding 0000:05:00.0?)
Actually, if I read things right, I think 3.2.4 did touch the device
too, just without the message.
One of the things that the aspm patch does is to remove the code that used to do
- if (aspm_clear_state)
- return -EINVAL;
in pcie_aspm_sanity_check(). So what I think happened for Matthias in
3.2.4 is that "pcie_aspm_sanity_check()" *always* failed (silently).
Which caused us to disable ASPM for *every* device, and not even talk
about it.
With the new patch in place, 3.2.5 gets past that check, and
pcie_aspm_sanity_check() now fails (with the message) for *some*
devices. Which then causes us to disable ASPM for *those* devices, but
not others. And that just sounds insane. It's sounds very broken for
this situation, because the BIOS had apparently enabled ASPM for the
PCIe bridge and the soubdblaster device, but then the "sanity check"
disabled ASPM for the bridge (and presumably left it on for the
soubdblaster).
Resulting in a broken system - aspm on the device, but not the bridge
leading up to it. Which I do not think is a correct situation.
So aspm=force fixes the issue because it forces aspm for everything -
which is fine. And 3.2.4 worked, because it *cleared* aspm for
everything. But 3.2.5 (and presumably current -git) does not work,
presumably because it clears ASPM randomly for bridge devices, while
leaving it on for the devices they bridge to.
Quite frankly, I think the pcie_aspm_sanity_check() logic is
fundamentally broken. It's broken because it violates the whole point
of the new model: it touches ASPM state for devices that firmware has
set up, and it shouldn't touch it for!
(It's also broken because it fundamentally makes the aspm disable be
"per device", which seems totally wrong - aspm is a system issue, you
can't just willy-nilly randomly enable it for one device without
taking other devices into account).
So I suspect the whole pcie_aspm_sanity_check() function should go away.
Matthias - can you try to trivially just make pcie_aspm_sanity_check()
always return 0 - remove the contents of that function, and just
replace them all with just a simple "return 0;". Does that make things
work for you?
Linus
On Tue, Feb 07, 2012 at 08:29:32AM -0800, Linus Torvalds wrote:
> Resulting in a broken system - aspm on the device, but not the bridge
> leading up to it. Which I do not think is a correct situation.
Per spec, it's valid. If there's a bridge that can't deal with its
downstreams having ASPM enabled when it has ASPM disabled then we
probably need to quirk that specially.
> (It's also broken because it fundamentally makes the aspm disable be
> "per device", which seems totally wrong - aspm is a system issue, you
> can't just willy-nilly randomly enable it for one device without
> taking other devices into account).
It's at *least* a per-bus thing, not a per-system thing. And, by the
spec, it's completely valid to have a different set of states configured
on the bridge and any downstream devices.
> So I suspect the whole pcie_aspm_sanity_check() function should go away.
The sanity check is important because nobody tests ASPM with pre-1.1
devices. However, in the aspm-is-disabled-by-FADT case, I can believe
that we should skip it.
--
Matthew Garrett | [email protected]
On 07.02.2012 08:29, Linus Torvalds wrote:
> [ Matthew wasn't cc'd for this thread - see lkml or ask me or Greg to
> forward you the relevant emails ]
>
> On Tue, Feb 7, 2012 at 4:28 AM, Clemens Ladisch <[email protected]> wrote:
> >
> > According to your logs, 3.2.4 didn't touch device 5:0, while 3.2.5 does
> > disable ASPM. ?(Are there any other messages regarding 0000:05:00.0?)
>
> Actually, if I read things right, I think 3.2.4 did touch the device
> too, just without the message.
>
> One of the things that the aspm patch does is to remove the code that used to do
>
> - if (aspm_clear_state)
> - return -EINVAL;
>
> in pcie_aspm_sanity_check(). So what I think happened for Matthias in
> 3.2.4 is that "pcie_aspm_sanity_check()" *always* failed (silently).
> Which caused us to disable ASPM for *every* device, and not even talk
> about it.
>
> With the new patch in place, 3.2.5 gets past that check, and
> pcie_aspm_sanity_check() now fails (with the message) for *some*
> devices. Which then causes us to disable ASPM for *those* devices, but
> not others. And that just sounds insane. It's sounds very broken for
> this situation, because the BIOS had apparently enabled ASPM for the
> PCIe bridge and the soubdblaster device, but then the "sanity check"
> disabled ASPM for the bridge (and presumably left it on for the
> soubdblaster).
>
> Resulting in a broken system - aspm on the device, but not the bridge
> leading up to it. Which I do not think is a correct situation.
>
> So aspm=force fixes the issue because it forces aspm for everything -
> which is fine. And 3.2.4 worked, because it *cleared* aspm for
> everything. But 3.2.5 (and presumably current -git) does not work,
> presumably because it clears ASPM randomly for bridge devices, while
> leaving it on for the devices they bridge to.
>
> Quite frankly, I think the pcie_aspm_sanity_check() logic is
> fundamentally broken. It's broken because it violates the whole point
> of the new model: it touches ASPM state for devices that firmware has
> set up, and it shouldn't touch it for!
>
> (It's also broken because it fundamentally makes the aspm disable be
> "per device", which seems totally wrong - aspm is a system issue, you
> can't just willy-nilly randomly enable it for one device without
> taking other devices into account).
>
> So I suspect the whole pcie_aspm_sanity_check() function should go away.
>
> Matthias - can you try to trivially just make pcie_aspm_sanity_check()
> always return 0 - remove the contents of that function, and just
> replace them all with just a simple "return 0;". Does that make things
> work for you?
So 3.2.5 with the following patch and without pcie_aspm=force:
- snip -
--- drivers/pci/pcie/aspm.c.orig 2012-02-07 15:17:05.068401852 +0100
+++ drivers/pci/pcie/aspm.c 2012-02-07 17:47:27.304684977 +0100
@@ -500,6 +500,8 @@
int pos;
u32 reg32;
+ return 0;
+
/*
* Some functions in a slot might not all be PCIe functions,
* very strange. Disable ASPM for the whole slot
- snip -
Sound works. :-)
dmesg | grep -i aspm
[ 0.762726] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.792913] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 1.627719] e1000e 0000:03:00.0: Disabling ASPM L1
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Ok. Can you try this?
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 1cfbf22..24f049e 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -500,6 +500,9 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
int pos;
u32 reg32;
+ if (aspm_disabled)
+ return 0;
+
/*
* Some functions in a slot might not all be PCIe functions,
* very strange. Disable ASPM for the whole slot
--
Matthew Garrett | [email protected]
On 07.02.2012 16:59, Matthew Garrett wrote:
> Ok. Can you try this?
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 1cfbf22..24f049e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -500,6 +500,9 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
> int pos;
> u32 reg32;
>
> + if (aspm_disabled)
> + return 0;
> +
> /*
> * Some functions in a slot might not all be PCIe functions,
> * very strange. Disable ASPM for the whole slot
>
Works too. What is the difference (in my case)?
dmesg looks the same.
dmesg | grep -i aspm
[ 0.761712] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.792916] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 1.626739] e1000e 0000:03:00.0: Disabling ASPM L1
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On Tue, Feb 07, 2012 at 06:07:09PM +0100, Matthias Schniedermeyer wrote:
> Works too. What is the difference (in my case)?
In your case, nothing. For other systems it means that we'd still refuse
to enable ASPM on pre-1.1 devices.
--
Matthew Garrett | [email protected]
On 07.02.2012 15:52, Matthias Schniedermeyer wrote:
> I guess this whole mess is Mainboard specifc.
> I have a another, very similar system but with an Asus P8H67-M PRO
> Mainbaord.
>
> I just remotly booted that machine into 3.2.5, so i can't verify if the
> sound works, but as the dmesg-output appears identical to the previous
> boot of 3.2.0 so i guess i will work.
>
> This is all i get for the system for aspm
> dmesg | grep -i aspm
> [ 0.777824] e1000e 0000:02:00.0: Disabling ASPM L0s
>
> So that mainboard has another BIOS/UEFI-Firmware and the
> PCIe-PCI-Bridge, the Soundblaster-Live is behind, is from another
> manufacture.
>
> lspci -v -s 5:0
> 05:00.0 PCI bridge: ASMedia Technology Inc. ASM108x PCIe to PCI Bridge Controller (rev 01) (prog-if 01 [Subtractive decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=05, secondary=06, subordinate=06, sec-latency=32
> I/O behind bridge: 0000b000-0000bfff
> Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 8489
Now that i'm back home i could test this other machine.
Unpatched 3.2.5 works fine, i guess because of the different Bridge-Chip
and/or Firmware.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On Tue, Feb 07, 2012 at 04:59:44PM +0000, Matthew Garrett wrote:
> Ok. Can you try this?
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 1cfbf22..24f049e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -500,6 +500,9 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
> int pos;
> u32 reg32;
>
> + if (aspm_disabled)
> + return 0;
> +
> /*
> * Some functions in a slot might not all be PCIe functions,
> * very strange. Disable ASPM for the whole slot
>
Matthew, this doesn't look like it made it into Linus's tree, don't we
still need this for 3.3-final?
thanks,
greg k-h
On Mon, Feb 27, 2012 at 04:13:09PM -0800, Greg KH wrote:
> On Tue, Feb 07, 2012 at 04:59:44PM +0000, Matthew Garrett wrote:
> > Ok. Can you try this?
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 1cfbf22..24f049e 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -500,6 +500,9 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
> > int pos;
> > u32 reg32;
> >
> > + if (aspm_disabled)
> > + return 0;
> > +
> > /*
> > * Some functions in a slot might not all be PCIe functions,
> > * very strange. Disable ASPM for the whole slot
> >
>
> Matthew, this doesn't look like it made it into Linus's tree, don't we
> still need this for 3.3-final?
Yeah, I'll post this properly. I think it probably is the correct
solution.
--
Matthew Garrett | [email protected]