Linux 3.2.5

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

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.

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.

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".

Does this mean that the new kernel _dis_ables ASPM, where it left it enabled previously?

Please try that kernel parameter.

Regards,
Clemens

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>

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.

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.

In your case, it appears that sound requires ASPM.

Regards,
Clemens

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.

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

So i am now running 3.2.5 with pcie_aspm=force and i have sound.

[    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

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 ]

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

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 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.

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]

So 3.2.5 with the following patch and without pcie_aspm=force:

- snip -

@@ -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?

index 1cfbf22..24f049e 100644
@@ -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]

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]

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.

Yeah, I'll post this properly. I think it probably is the correct solution.

Matthew Garrett | [email protected]