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]

Date:	Wed, 3 Dec 2008 07:53:53 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
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 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. However, even if it 
fixes things for you, I think we're too late in the 2.6.28 cycle to really 
apply this.

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.

			Linus

---
 drivers/pci/setup-bus.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ea979f2..586451c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -467,8 +467,12 @@ void __ref pci_bus_size_bridges(struct pci_bus *bus)
 		}
 	}

-	/* The root bus? */
-	if (!bus->self)
+	/*
+	 * We don't need to allocate PCI bridging windows
+	 * for a root bus (everything bridged) or for a
+	 * transparent one.
+	 */
+	if (!bus->self || bus->self->transparent)
 		return;

 	switch (bus->self->class >> 8) {
--
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/