The bisect of commits to Kernel 3.0.0-16.28 .. 30.0.0-16.29 produced the following result. I dont understand what that means but it will hopefully provide the informations you need to continue debugging or fix the bug:
df89d48a8cbdc23578397c6e62d5c9c9e630c610 is the first bad commit
commit df89d48a8cbdc23578397c6e62d5c9c9e630c610
Author: Matthew Garrett <email address hidden>
Date: Thu Nov 10 16:38:33 2011 -0500
Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
"PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.
This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.
It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.
Measured to save around 5W on an idle Thinkpad X220.
:040000 040000 2ae424c4b73d5552809986f7116ba347b4fb1a90 04a4a42154f00a9c3a47ec3f787e424437b06183 M drivers
:040000 040000 72de932be7dafa9fa5712bc854a332850c0a79ac 94d1f2df9527e35ddc9d6489c2de6545fad4c764 M include
The bisect of commits to Kernel 3.0.0-16.28 .. 30.0.0-16.29 produced the following result. I dont understand what that means but it will hopefully provide the informations you need to continue debugging or fix the bug:
df89d48a8cbdc23 578397c6e62d5c9 c9e630c610 is the first bad commit 578397c6e62d5c9 c9e630c610
commit df89d48a8cbdc23
Author: Matthew Garrett <email address hidden>
Date: Thu Nov 10 16:38:33 2011 -0500
PCI: Rework ASPM disable code
BugLink: http:// bugs.launchpad. net/bugs/ 927848
commit 3c076351c4027a5 6d5005a39a0b518 a4ba393ce2 upstream.
Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
"PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.
This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.
It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.
Measured to save around 5W on an idle Thinkpad X220.
Signed-off-by: Matthew Garrett <email address hidden>
Signed-off-by: Jesse Barnes <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
:040000 040000 2ae424c4b73d555 2809986f7116ba3 47b4fb1a90 04a4a42154f00a9 c3a47ec3f787e42 4437b06183 M drivers fa5712bc854a332 850c0a79ac 94d1f2df9527e35 ddc9d6489c2de65 45fad4c764 M include
:040000 040000 72de932be7dafa9