linux-kernel - Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

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]

Message-Id: <200812050031.27287.rjw@sisk.pl>
Date:	Fri, 5 Dec 2008 00:31:26 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Frans Pop <elendil@...net.nl>, Greg KH <greg@...ah.com>,
	Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
	lenb@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > However, this one appears to work reliably for me (on top of vanilla current
> > mainline):
> 
> Not very interesting. It just does the same thing your previous patches 
> have done - ignores the cardbus slot for sizing. It just does it 
> differently and more explicitly.

There's a difference, though.  It doesn't cause the resources flags to be
cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
of both prefetchable and non-prefetchable windows (64 MB).

> Your original patch did it by simply giving the resources invalid 
> alignments (in a very non-obvious way). This one does it by being explicit 
> and saying "we won't care about cardbus resources behind transparent 
> bridges". But it's still a very hacky thing, and thus not really 
> interesting at all as a patch.
> 
> IOW, it's not a patch that makes sense - it's just a patch that ON YOUR 
> PARTICULAR MACHINE causes us to get the layout you want in order to hide 
> the bug.

I know that. :-)  Still, I find it important to notice that the memory windows
of the cardbus bridge can be 64 MB-wide and things work in that case too.
Also, I like it more than the previous patch. ;-)

Moreover, I _think_ it would work for Frans too, because I _suspect_ the
problem is related to a cardbus bridge being located behind that "transparent"
thing somehow.

> And it doesn't really even do anything new - it's just doing the  
> same thing in an old way.
> 
> But it's interesting that the "don't size _anything_ behind a transparent 
> bridge" apparently made no difference for you.
> 
> Can you send "lspci -vv" and "dmesg" output for that kernel?

No prob, both attached along with the contents of /proc/iomem .

> Even if it failed the suspend/resume, it's interesting, because I would
> actually have expected that one to have the same layout as the successful
> ones. 

Well, not exactly.  Actually, with this patch the graphics and "ICH HD audio"
get their memory ranges before the ranges of _all_ devices behind the
transparent bridge, while in the "working" case their memory ranges are located
_after_ the memory ranges of devices behind the transparent bridge _except_
for the cardbus bridge's memory windows.

Thanks,
Rafael

View attachment "dmesg.log" of type "text/x-log" (54515 bytes)

View attachment "lspci-vv.txt" of type "text/plain" (18833 bytes)

View attachment "proc_iomem.txt" of type "text/plain" (2071 bytes)