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: <200812040223.54341.rjw@sisk.pl>
Date:	Thu, 4 Dec 2008 02:23:53 +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 Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Then, voila!, I'm not able to reproduce the hibernation-resume failure.
> > 
> > This appears to mean that:
> > (1) The sizes of the allocations and the locations of devices in the memory
> >     address space don't matter here.
> > (2) The presence and size of the prefetchable memory window don't matter here.
> > (3) What matters is the presence of non-prefetchable memory window on the
> >     supposedly transparent bridge.  Namely, if the window is there, resume from
> >     hibernation occasionally fails (again, the size of the window and the
> >     location of it in the memory address space doesn't seem to matter).
> 
> That is indeed rather odd, and very interesting. 
> 
> > So, apparently, on this box (and I guess on Frans' too) we could avoid the
> > problem if we didn't allocate the non-prefetchable memory window in
> > pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.
> 
> Well, I think that what _would_ be generally correct, and actually pretty 
> simple, is a rather different approach: just not sizing things behind a 
> transparent bridge AT ALL, since it really shouldn't matter.
> 
> So if the appended patch fixes things for you, I think this might 
> potentially be the right approach.
> 
> NOTE NOTE NOTE! This patch is entirely untested, as usual. I didn't check 
> that this is necessarily the correct place to test for this, but it 
> does make sense. IOW, it _feels_ like the rigth thing.

Yes, it _looks_ sane.

> However, even if it fixes things for you, I think we're too late in the
> 2.6.28 cycle to really apply this.

Absolutely.

> So it really does make sense to consider a root bridge and a transparent 
> one to be equivalent here, since in both cases any bridge windows should 
> be irrelevant. Which is why I think this patch is interesting.
> 
> > Also, I would be happy to actually understand _why_ this happens.
> 
> 100% agreed. I do _not_ see why it should ever matter how we set up a PCI 
> bridging window - whether prefetchable or not - on a bridge that should be 
> transparent. It sounds really odd. I'm wondering if there is something 
> we're missing here.
> 
> But apart from the existence of the bridging window, the only thing that 
> it seems to affect is really just a minor layour issue. So it does seem 
> like it matters. Odd.

Well, in principle it may be related to the way we handle bridges during
resume, but I really need to read some docs and compare them with the code
before I can say anything more about that.  Surely, nothing like this issue has
ever been reported before.

Anyway, thanks for the patch, I'm going to try it tomorrow.

Best,
Rafael
--
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/