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
| ||
|
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/
Powered by blists - more mailing lists