linux-kernel - Re: [ 06/41] PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 1 Apr 2012 17:11:08 +0100
From:	Ken Moffat <zarniwhoop@...world.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Matthew Garrett <mjg@...hat.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [ 06/41] PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled

On Sat, Mar 31, 2012 at 04:23:56AM +0100, Ken Moffat wrote:

[ update : 3.4.0-rc1 boots without reverting this ]
> On Fri, Mar 16, 2012 at 04:38:16PM -0700, Greg KH wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Matthew Garrett <mjg@...hat.com>
> > 
> > commit 4949be16822e92a18ea0cc1616319926628092ee upstream.
> > 
> > Right now we won't touch ASPM state if ASPM is disabled, except in the case
> > where we find a device that appears to be too old to reliably support ASPM.
> > Right now we'll clear it in that case, which is almost certainly the wrong
> > thing to do. The easiest way around this is just to disable the blacklisting
> > when ASPM is disabled.
> > 
> > Signed-off-by: Matthew Garrett <mjg@...hat.com>
> > Signed-off-by: Jesse Barnes <jbarnes@...tuousgeek.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > 
> 
>  Sorry for the late response, but I bought a new machine this week
> (low-end i3) and this has bitten me.  I prepared a "generic" x86_64
> kernel using 3.2.9, which I hoped would be good enough to get me
> started, and later prepared another using 3.3.0.  Long story short -
> 3.2.9 was adequate, 3.3.0 crashes early in boot (before switching
> from the 80x25 console to kms).  All the interesting part has
> scrolled off the screen, and it's too early to get logged.
> 
[...]
>   Trial and error showed this commit seemed to be the
> problem.
> 
>  I then reverted this commit from 3.3.0, and took my amended .config
> which works adequately in vanilla 3.2.8.  I'm now running that.
> 
 BUT, for 3.4.0-rc1 I don't need to revert it - just went with the
defaults for additions in menuconfig, and it boots fine.  Maybe
something else needs to be backported ?

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/