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

[Rafael J. Wysocki]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/